CodeIgniter

Introduction

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.

About CodeIgniter

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 our framework:

• Small footprint with exceptional performance • MVC approach to development (although it is very loosely based which allows for

flexibility) • 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

1

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 the data.

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 console.

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 objectives:

• 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.

2

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 database details.

• 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

application. • 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

application. • 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

library. • 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.

3

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 CodeIgniter.

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

execution. 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.

Limitations

• 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 applications.

• 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 3rd Party libraries or plugins it would be great to have them right out of the box.

4

Bibliography

***, http://codeigniter.com/wiki/Tutorials/David Upton, Codeigniter for rapid php application development, Packt Publishing 2007Thomas Myer, Professional CodeIgniter, Wrox 2008

5