July 13, 2009

Some CodeIgniter Gotcha's

Maybe I'm doing something wrong. In fact, for the sake of programming, I hope I am. But for the life of me, I can't find a single benefit of PHP frameworks that isn't overshadowed by the negatives.

(Update: I have made the switch to Python/Django, and have no intentions of looking back.)

PHP frameworks make it easy to start out— meaning that, when facing a new project, they seem like a good idea. You don't have to do all the boring stuff at first— and when you are starting a new project, that is a tempting proposition.

This topic deserves a much more thorough analysis (which many before me have done, and I am sure I someday will), however after spending the weekend struggling with CodeIgniter, I figured I wouldd mention some CodeIgniter-specific problems I have come across.

Debugging

When I started programming, things took me a while. I didn't use frameworks- I did everything from scratch. However, despite the time commitment, I was making progress- it was time consuming, but it wasn't frustrating. It felt rewarding- plugging along in Notepad.exe, making slow but steady progress. Then, things changed. I started using PHP frameworks- and things started to go downhill. Rather than investing my time in programming, I started spending more and more time debugging. And debugging became harder- after all, frameworks tend to break native error reporting to a certain extent.

Here is the code:

$this->load->model('whatever');

Here's the problem- IDEs and even PHP itself has a hard time following that. A lot of times, errors will show up as being in the Load or Model classes- not helpful, when you know the actual problem is in your code.

Like, this error:

Filename: libraries/Model.php Line Number: 70

The error is in my code, not the file/line given. Where is it? Your guess is as good as mine- CodeIgniter isn't telling.

Conventions

CodeIgniter almost seems to take pride in being illogical when it comes to conventions. While PHP's conventions may be laughable, CodeIgniter's are prohibitive.

For example, what is the output of this code? (And, let's assume these two lines are on separate pages- otherwise, the cookie wouldn't yet be set.)

set_cookie('test', 'value'); echo get_cookie('test');

I know what you're thinking- and you're wrong. It's not "test." For whatever reason (which isn't documented in the documentation), set_cookie() automatically appends the prefix from the config files, while get_cookie() does not. So, you would have to do the following to get the expected results:

set_cookie('test', 'value'); echo get_cookie('prefix_test');

Great, huh? I'm sure the reason is so that you can read any cookie, however it makes the whole thing incredibly confusing.

Another example is callbacks. Maybe this is a standard practice, who knows. But I don't like it. In CodeIgniter, for validation, you can specify a rule. So, something like this:

$rules['email'] = "required|valid_email|unique_email";

The "unique_email" part is a custom function- and it has to be called unique_email_callback. I have two problems with this. One, it's not easy to figure out unless you read the docs- code should be easy to follow. And, secondly, why are these callback functions written as strings? This is code- I shouldn't be writing out function names as strings. It makes it much harder to follow.

Attaching Libraries/Models/etc To Everything

Maybe the biggest problem is that if you load any sort of library, view, or model- it's attached to every single object. So, let's say you have an object, with a property called "parent."

So, this code works:

echo $whatever->parent; // Prints out '3'

Now, somewhere else on your page, in a completely different object, having nothing to do with $whatever, you do this:

$this->load->model('parent');

Your old code? No longer works:

echo $whatever->parent; // No longer '3'

Does this make sense, to a certain extent? Yes. Logically, yes. But, it is incredibly— you can't have, for example, a model with a 'section' attribute and also have a 'section' model. This has caused things to break for me more often that anything else- a perfect example of how changing something in one part of the code can affect something completely unrelated. Something that doesn't happen with straight up PHP.

And there's more

There's more. Lots more. And maybe someday, I will document more of the problems I have with frameworks. Or maybe I'll switch to something better. (Edit: Django!) But either way- I hate spending a day programming, only to get nothing done. PHP frameworks are bad at getting out of your way. Before frameworks, a day of programming may not have resulted in much, but it went at a steady pace and I knew X hours of programming would equal Y results. Now, I can spend a whole day trying to get something stupid simple working, with no results.

And I promise- whatever I write for Wednesday, it will be more upbeat!

About Gregory Koberger

I'm a freelance developer and designer, formerly of Mozilla. I talk a lot about web development, technology and user experience — sometimes on my blog but mostly on Twitter.

Keep Reading

Your Turn