I've spent the weekend trying out CodeIgnitor, a MVC framework for PHP. Reading their web site suggested CodeIgnitor would match my need for a framework which could take care of the basic, and usually extremely boring, building blocks inherent in a project of any size whilst at the same time avoiding the usually steep learning curve and bloated feature sets of other such frameworks.
CodeIgnitor seems to offer an easier introduction to MVC and I like the fact that it offers flexibility over whether to choose full blown MVC or a more reduced and, in some cases, optimal View-Controller configuration. In certain situations I feel the addition of "Models" is an abstraction level too far.
Setup was a breeze:
- Unzip the files into your web directory
Add the following .htaccess file to handle the mod rewrite rules:
RewriteRule ^$ /index.php [L]
RewriteRule ^(.*)$ /index.php/$1 [L]
It's worth pointing out that the documentation on the .htaccess rules misses out the second line (
RewriteRule ^$ /index.php [L]) which is vital if you want CodeIgnitor to load the default view from the document root (/).
- Remove "index.php" from
$config['index_page'] = "index.php";in the system/application/config/config.php.
The CodeIgnitor site offers clear and concise documentation with simple code examples detailing every feature of the framework. There are also instructions on how to build on the default feature set. For me this is the greatest selling point and an area where many of the other frameworks fall short.
Another area where CodeIgnitor scores strong points is on its use of PHP as its main templating language. Whilst it does provides a simplistic templating class for those that might want it the author expresses his preference, and the obvious performance advantages, for using raw PHP.
Basic scaffolding functionality is provided but it should really only be considered for development purposes and it lacks the security features which would be required of a full blown site admin system. This is a shame and one weak area of CodeIgnitor particularly when compared to the fantastic interfaces offered by frameworks such as Django. That said it could probably be easily expanded or replaced using CodeIgnitor's plugin architecture.
This plugin architecture is made up of "helpers", "plugins" and "scripts". "Helpers" consist of simple sets of procedural functions which perform common tasks such as date formatting, string and cookie manipulation. The author suggests these form part of the core system but I can see situations where you might want to add to this default set. "Plugins" are used for more extensive functionality - the two examples included are a CAPTCHA and a calendar. The purpose of "scripts" is somewhat less clear although I get the impression the "scripts" directory is a place to store any other library code you might have that you wouldn't really consider to be a proper part of the CodeIgnitor framework.
Database manipulation is provided through a vendor independent database class. This provides support for the "Active Record Database" pattern which, in most cases, removes the need to write SQL queries. A separate pagination class provides the ability to page through database results sets as well as other data.
CodeIgnitor supports full page caching ensuring your application won't need to hit the database on each page request. Pages are cached for a specified number of seconds in temporary files written to the "system/cache" directory. If you find this feature doesn't work out of the box you may need to change the file permissions for the directory to allow the web server process (most likely Apache) to write to it. Fragment caching isn't currently supported but again could easily be added and will probably be something I'll look into implementing as a plugin.
Generally CodeIgnitor seems to be really well thought out and the code is clean and easy to follow. When I get time I'll be looking to convert this site to use it. Given my experiences so far I doubt it will take me too long.