Software applications nowadays and especially web applications tend to be prototyped and
developed in a short amount of time. This is why developers tend to have a RAD (Rapid
Application Development ) approach and use frameworks in developing applications. RAD
approaches may entail compromises in functionality and performance in exchange for enabling
faster development and facilitating application maintenance, but the frameworks compensate some
of these compromises.
On the market there are many frameworks based on several programming languages, but in
this tutorial we are going to focus ourselves on CodeIgniter a PHP framework developed by
EllisLab. Our main focus in this paper is on this framework, but we will try do a comparison with
several similar frameworks to see the difference in performance, concepts and techniques.
CodeIgniter is a very light, easy to use and well performing framework. While, it is perfect
for a beginner, it's also perfect for large and demanding web applications. CodeIgniter is developed
by EllisLab, as we said earlier, and has an easy to understand documentation and a lot of
educational resources. Below we presented a list of reasons of what makes us choose CodeIgniter as
• Small footprint with exceptional performance
• MVC approach to development (although it is very loosely based which allows for
• Generates search engine friendly clean URLs
• Runs on both PHP 4 and 5
• Support for most major databases including MySQL, MySQLi, MS SQL, Postgres, Oracle,
SQLite, and ODBC.
• Easy caching operations
• Many libraries and helpers to help you with complex operations such as email, image
manipulation, form validation, file uploading, sessions, multilingual apps and creating apis
for your app
• Most libraries are only loaded when needed which cuts back on resources needed.
CodeIgniter uses the Model-View-Controller (MVC) approach similar to most available
frameworks, however, it is a bit loose in it’s approach to MVC as a model does not have to be used.
As we mention it is lightweight, which means it starts you off with just the basic libraries and you
can load more if needed. Regarding libraries, the framework comes with a nice selection of libraries
to get you going quickly, such as connecting to a database, sending email, validating form data,
maintaining sessions, manipulating images, and more. Another important aspect is that the user
guide comes with the installation files and community forums are active and contain a lot of helpful
answers to several problems.
Besides the MVC approach CodeIgniter uses scaffolding which is an automated way of
generating a view based on the model. Scaffolding is meant for simple prototyping and CodeIgniter
takes it a step further by requiring a keyword in the URL to even access the scaffolding.
PHP frameworks have mostly the same functions and options,this is why we are going to
compare Codeigniter with a different language framework, Django which is based on Python.
Both frameworks use a MVC approach, rely on rapid development and the DRY (Don't
Repeat Yourself) principle.
Django provides an optional administrative "CRUD" interface that is generated dynamically
through introspection and configured via admin models. This is a very useful feature when handling
We can spot some advantages of the PHP framework right away given by the installation
issues of Django:
1. Django installation and configuration assumes you have access to a shell, although we could
offer installation service, but not on specific servers.
2. Django runs only on some specific hosts that take must take special care to enable it,
installing mod_python/mod_wsgi which is a problem if you don't have access to the
3. Using PHP would mean we could run it on their existing server: this means no need to move
them to a Django-enabled server, and no downtime for their emails, while DNS updates.
From a performance point of view Django has a clear advantage due to the least use of the
processor. Also the core of the Django framework consists of an object-relational mapper which
mediates between data models and a relational database; a regular-expression-based URL
dispatcher; a view system for processing requests; and a templating system. Most of these functions
don't exist or a limited in the CodeIgniter project.
Still CodeIgniter is the framework we chose for simplicity purposes and wide extension of
the php language, and the fact that CodeIgnier projects are easier to handle, and run “right of the
box” than the Django projects wich require a running server.
CodeIgniter – Architectural description
As the makers of CodeIgniter mention on the user guide, the framework was built for:
“maximum performance, capability, and flexibility in the smallest, lightest possible package”.
To meet this goal we are committed to benchmarking, re-factoring, and simplifying at every step of
the development process, rejecting anything that doesn't further the stated objective.
From a technical and architectural standpoint, CodeIgniter was created with the following
• Dynamic Instantiation. In CodeIgniter, components are loaded and routines executed only
when requested, rather than globally. No assumptions are made by the system regarding
what may be needed beyond the minimal core resources, so the system is very light-weight
by default. The events, as triggered by the HTTP request, and the controllers and views you
design will determine what is invoked.
• Loose Coupling. Coupling is the degree to which components of a system rely on each
other. The less components depend on each other the more reusable and flexible the system
becomes. Our goal was a very loosely coupled system.
• Component Singularity. Singularity is the degree to which components have a narrowly
focused purpose. In CodeIgniter, each class and its functions are highly autonomous in order
to allow maximum usefulness.
The system folder stores all the files which make CodeIgniter work.
• The application folder is almost identical to the contents of the system folder this is
so the user can have files that are particular to that application, for example if a user
only wanted to load a helper in one application he would place it in the
system/application/helpers folder instead of the system/helpers folder.
• The config folder stores all the config files relevant to the application. Which
includes information on what libaries the application should auto load and
• The controllers folder stores all the controllers for the application.
• The errors folder stores all the template error pages for the application. When
an error occurs the error page is generated from one of these templates.
• The helpers folder stores all the helpers which are specific to your
• The hooks folder is for hooks which modify the functioning of CodeIgniter's
core files, hooks should only be used by advanced users of CodeIgniter
• The language folder stores lines of text which can be loaded through the
language library to create multilingual sites.
• The libraries folder stores all the libraries which are specific to your
• The models folder stores all the models for the application.
• The views folder stores all the views for the application.
• The cache folder stores all the caches generated by the caching library.
• The codeigniter folder stores all the internals which make CodeIgniter work.
• The database folder stores all the database drivers and class which enable you to
connect to database.
• The fonts folder stores all the fonts which can be used by the image manipulation
• The helpers folder stores all of CodeIgniter's core helpers but you can place your
own helpers in here which can be accessed by all of your applications.
• The language folder stores all of CodeIgniter's core language files which its libaries
and helpers use. You can also put your own language folders which can accessed by
all of your applications.
• The libaries folder stores all of CodeIgniter's core libaries but you can place your
own libraries in here which can be accessed by all of your applications
• The logs folder stores all of the logs generated by CodeIgniter.
• The plugin folder stores all of the plugins which you can use. Plugins are almost
identical to helpers, plugins are functions intended to be shared by the community.
• The scaffolding folder stores all the files which make the scaffolding class work.
Scaffolding provides a convenient CRUD like interface to access information in your
database during development.
• The user_guide houses the user guide to CodeIgniter.
• The index.php file is the bit that does all the CodeIgniter magic it also lets the you change
the name of the system and application folders.
The following graphic illustrates how data flows throughout the system:
1. The index.php serves as the front controller, initializing the base resources needed to run
2. The Router examines the HTTP request to determine what should be done with it.
3. If a cache file exists, it is sent directly to the browser, bypassing the normal system
4. Security. Before the application controller is loaded, the HTTP request and any user
submitted data is filtered for security.
5. The Controller loads the model, core libraries, plugins, helpers, and any other resources
needed to process the specific request.
6. The finalized View is rendered then sent to the web browser to be seen. If caching is
enabled, the view is cached first so that on subsequent requests it can be served.
• The first major issue with the framework is how it deals with retrieving and manipulating
data from the database.
• CodeIgniter's models are optional and serve no function other than code separation. There's
no integrated CRUD and its "Active Record" class is really just an alternative SQL syntax. It
also doesn't support table associations. So, you will be building many large queries
essentially from scratch.
• CodeIgniter lacks some essential libraries that are needed in most applications (i.e.
Authentication and ACL). You will need to rely on 3rd party libraries in many of your
• Since CodeIgniter lacks much of the automation, there are no strict conventions to follow.
This makes CodeIgniter a more flexible framework. Furthermore, its lack of features and
automation do give it an advantage when it comes to speed.
Improving these limitations would give a great boost to the CodeIgniter framework and
make it more powerful. Although some of the limitations are fixed via 3 rd Party libraries or plugins
it would be great to have them right out of the box.
David Upton, Codeigniter for rapid php application development, Packt Publishing 2007
Thomas Myer, Professional CodeIgniter, Wrox 2008