About CodeIgniter

I think I’ve mentioned here before that I picked up PHP at the beginning of last year. Almost immediately I started doing projects for clients with it. Aside from the very infrequent bug fix to Approver.com and my VSLive demos, I hardly did any C# coding last year.

As I was coming up to speed on PHP, there was something about it that I (and many others) found maddening. It drove me crazy that three different PHP developers could come up with the same solution to the same problem in three different ways, and the fact that there are (for example) at least three database libraries to use PHP with MySQL wasted a ton of time. I’ve become a big fan of database abstraction layers over the past few years; in particular, Active Record and model-view-controller (MVC) appealed to me, although I was dispassionate about having to learn a whole new language like Ruby to get it, particularly after having just learned PHP. So in short, at the end of last year I found myself shopping for some kind of PHP framework.

I researched PHP frameworks a bunch on a project for an entertainment industry client back in December, creating prototype versions of their existing web site in both CakePHP and CodeIgniter. CodeIgniter was far and away the winner of the bake-off (particularly after it received the endorsement of my former Yahoo! colleague Rasmus Lerdorf).

CodeIgniter is nice because it makes the patterns for putting together applications obvious, but unlike other MVC frameworks it’s not doctrinaire. You can name stuff (like database tables and controller classes) whatever you like; it even lets you eschew the use of models completely if you want. I like this because it reduces complexity at the cost of the “separation of concerns” that MVC aficionados tout; I suspect that purists will be offended by this but I find it to be liberating.

CodeIgniter has a lot of other higher-level niceties — dozens of libraries and helper classes, including such as a session management library, parsers for various kinds of data, even an abstraction layer on top of image-handling libraries. There’s provisions for extensibility, but there’s no crazy plug-in API or anything — writing your own libraries is as easy as writing a class and writing your own helper is as easy as writing a function.

Getting stuff out of the database using CodeIgniter’s modified active record implementation is pretty simple too. After loading CodeIgniter’s database class library, you can write queries like this:

$query = $this->db->get_where('people', array('id' => 449587));

You can also add where clauses, sort conditions and so forth:

$this->db->select('first_name', 'last_name');
$this->db->where('id', 449587);
$this->db->order_by('last_name, first_name');
$query = $this->db->get();

It’s possible to chain all these conditions together on a single line, but I prefer putting them on separate lines for readability.

There are tons of other ways to get data using CodeIgniter’s ActiveRecord implementation, but you also have full SQL queries if you need them:

$query = $this->db->query('SELECT id, first_name, last_name FROM people');

Ultimately, get_where() is the naive case, and certainly the most commonly-used in my code anyway — I can’t think of a other framework in any other language that enables you to be this productive with data with a single line of code.

So I’m basically using CodeIgniter every day now, and the plan is to use CodeIgniter for all our PHP projects in the future, including Facebook applications. We’ve already done one Facebook app using CodeIgniter and that project went pretty well. We also used CodeIgniter for the Tinypug customer innovation platform that we just released yesterday as an open-source project.