CodeIgniter for Webapps

| March 29th, 2010

In a totally non Cocoa-related post, I just wanted to give my quick thoughts on CodeIgniter.In case no one has guessed, I really like Ruby and Ruby on Rails, even though I don’t get to often use them. However there’s a few issues that make it not always practical. First, if you have a shared hosting service, then there’s a good chance they don’t support running Rails. Second, deployment of rails is a bit more involved than copying files to the server. Those aren’t really big deals if you’re making a web app that really needs the power, but I’m willing to admit Rails is overkill for my company website.

So as I was figuring out how I want to build my website, I looked at least briefly at a few LAMP-based solutions (A quick disclaimer: I’m not a ‘web developer’, so go easy on me if I say something erroneous or that you violently disagree with). I went from heavier weight frameworks (Joomla, ExpressionEngine) to considering just coding PHP pages myself when I found CodeIgniter which seemed just right (yes, the Goldilocks metaphor went through my head at the time I was checking it out).

What’s Great

Like a lot of frameworks today, CodeIgniter borrows heavily from Rails. It follows a similar MVC pattern, and uses a somewhat similar directory structure. I had actually never done any coding in PHP before this, and it helped a lot that it followed a familiar pattern, to reduce the amount I was learning at once.

Deployment is also simple. Other than needing to mess around with htaccess a bit to get the routing working like I wanted and setting up the database, it was just a matter of copying files to the server. Most of the site-specific configuration is located a few files, so just excluding those means updating the site is pretty easy.

Probably the thing I liked most about it is something that not everyone will like. I like to write code rather than click buttons to add new pages or content. I don’t really consider myself a control freak, but it drives me nuts that I can’t see or at least don’t have a good picture in my head on what’s going on behind the scenes to make a web page appear. Perhaps I’m being unfair when I compare it to CMS frameworks like Joomla and ExpressionEngine, but these are the things I checked out when I went searching, so at very least they’re comparable as ‘frameworks to build a website with’.

What’s Less Than Great

The mapping from a URL to a controller method has one limitation that bothered me. You can configure it to pass parameters in the path, or in query string, but not both. For a full featured REST API this would really bother me, but it’s just a minor annoyance otherwise.

The framework’s support for models is kind of weak. Okay, it’s really weak. It’s really nothing more than ‘put your database code here’. No relationships, migrations, or any of the good stuff you may want. Once again though, I was developing simple company website with very few database needs, so it wasn’t a big deal.

The End Result

I was surprised by how both easy CodeIgniter and PHP was to pick up. I didn’t mind at all the temporary switch from Cocoa development, and won’t mind too much when I have to go and update it.

3 Responses to “CodeIgniter for Webapps”

  1. Ricardo Says:

    I use CodeIgiter too, it’s easy to install, easy to use and easy to grasp. At this link: the guy explain how he worked out a way to use the query string and the urls paths together. I hope it can help you.

  2. AceF Says:

    I actually like that it has a weak model. While Symfony and Cake have stricter rules for naming your tables and fields, CI relaxes that restriction which makes it easier to retrofit onto old, pre-framework dbs. It’s more work, but it’s worth it when you have a great degree of control.

  3. Pete Otaqui Says:

    You might want to check out CakePHP as an alternative to Code Ignitor. It also borrowed very heavily from Rails.

    It has a lot of the benefits of CI, while missing some of the downsides. You get a nice set of command-line tools (and the framework to write your own shells and tasks) for interacting with your app, “baking” various things like stub models / controllers / views, and dealing with schemas.

    You also get model relationships which can also be bound and unbound on the fly, your result sets can be “containers” for other things (so you specify exactly what you want back from the relationships).

    It’s also pretty easy to create your own data sources, this ecample from the docs shows you a method for using Twitter data for your model:

Leave a Reply