Gregory Koberger :: the blog

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 frameworks that isn’t overshadowed by the negatives.

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’re starting a new project, that’s a tempting proposition.

This topic deserves a much more thorough analysis (which many before me have done, and I’m sure I someday will), however after spending the weekend struggling with CodeIgniter, I figured I’d mention some CodeIgniter-specific problems I’ve 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 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’s 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, but CodeIgniter’s are prohibitive.

For example, what’s 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?

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’s confusing as hell- 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’ll document more of the problems I have with frameworks. Or maybe I’ll try to do something about it, and finish my own framework I started a while ago. But either way- I hate spending a day programming, and ending feeling frustrated. Frameworks are bad at getting out of your way (except you, jQuery- I love you). Before frameworks, a days worth 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’ll be more upbeat!