First Impressions of Code Igniter

Last night I was forced to start working with CodeIgniter, a PHP web-framework, and I have to say that so far I am enjoying the experience.

CodeIgniter provides a simple framework that allows you to quickly get an application up and running.  The learning curve (so far) has been very low.  I like web-frameworks for projects. I have done a number of projects in Ruby on Rails, and I have dabbled in Django. Those have been pleasant experiences, but I prefer PHP as my preferred development language for most projects due to a number of reasons (not interested in jumping into that holy war right now.)

Up to this point, if I wanted to use a PHP framework, my choices were Zend and CakePHP. Zend is a monster. I’m sorry, I know a lot of developers swear by Zend, but I’m not one of them. Nobody “quickly” picks up Zend. Zend is so incredibly dense/bloated/abstracted that debugging something becomes an exercise that is more time consuming than the original problem that you were trying to solve. CakePHP felt too much like I was pretending to be Ruby on Rails, and there were so many hoops to jump through. And it was frequently a little “too magical.”

After exploring these different options, I wrote my own framework that took the parts of Ruby on Rails that I enjoyed, but kept the flexibility and familiarity of PHP. I have been using this for over a year now and it has served me well. I was pleased to find that the structure of CodeIgniter was almost identical to the structure of my own framework. This has made it a very easy switch for me.

The only problem that I have run into so far was briefly not understanding how to get to a GET parameter in a fashion that didn’t make me feel dirty.

Tangent about accessing GET parameters coming…
CodeIgniter obscures the $_GET parameters by default, you can enable them within your configuration, but I am working on one page of an existing site as a favor for a friend.  The CodeIgniter documentation suggests that you retrieve the parameters based on “segments” so if you wanted to pass in

http://www.mysite.com/events.php?start=25&state=VA&count=50

CodeIgniter suggests that you would generate the url

http://www.mysite.com/events/index/25/VA/50

And then retrieve your parameters based on which “segment” they were.

segment(3) => 25 // the 'start' value
segment(4) => VA // the 'state' value
segment(5) => 50 // the 'count' value

This makes me cringe for many reasons. What if, for example, the user can click a link to change the count to 25, but it defaults to 50. Most of the time this isn’t going to happen, so would I ALWAYS assume that I’m passing in the first segment as the start param, even when it’s typically not going to be used?

uri_to_assoc to the rescue
The solution to this “issue” (it’s more of my own issue than an actual problem) was the function uri_to_assoc.
Using uri_to_assoc means that I could format my urls as:

http://www.mysite.com/events/index/start/25/state/VA/count/50

and then in my code use:

$params = $this->uri->uri_to_assoc(3);

/* I now have the array $params with:
* $params['state'] = 'VA'
* $params['state'] = 25
* $params['count'] = 50
*/

This makes me much more comfortable, as it means that it doesn’t matter where in the URI that my parameters are positioned.
Tangent finished
I plan to continue using CodeIgniter for a while, to see if it’s the right fit. I have some small projects that it would likely be quite appropriate for, and it will get me out of the business of supporting my own framework.