Christopher W. Allen-Poole professional blog

February 22, 2010

CodeIgniter reviews

Filed under: CodeIgniter, php — frageanonym @ 7:08 pm

People around me are likely already are already aware of the issues I have with CodeIgniter. Don’t get me wrong, it is a good framework overall, but I can’t help but think that there might be a better one.

First, it does not allow for the use of the magic __class function. Yes, it has a _resolve function which sort of does the same thing, but, realistically, this is bad practice. It is re-inventing the wheel needlessly.

The counter argument might be, “Well, it is supposed to be PHP 4 and PHP 5 compatible.” This may be true, but it is also true that CodeIgniter makes some exceptions when it comes to supporting PHP 4 — namely the Loader class cannot be extended. This makes that initial argument specious at best.

Further, the difference between support of the __class method and the method currently there is trivial. Here is what the native CodeIgniter library shows (line 228 in CodeIgniter.php):

if(!in_array(strtolower($method),array_map('strtolower', get_class_methods($CI))))

Here is my version:

If that weren’t enough, there is no easy way to get around lines 220 – 230 on CodeIgniter.php without writing over the system file. There should the a Router->isValidDestination( $class, $method ), which would mean that this is something which could be easily overridden by creating a MY_Router subclass.

The next issue, and this is arguably minor, is that they use the old @opendir style of reading a directory. Sure, it has its benefits over RecursiveDirectoryIterator (50% faster in preliminary speed tests to get the exact same results), but it is 5% slower than glob, an arguably superior function. Their directory_map( $dirname, TRUE, FALSE ); is the equivalent of glob( $dirname ); only much faster A simple recursive wrapper makes glob more effective. And, truth be told, the only reason that it is ever slower is because glob returns a path and filename, not just a filename. Admittedly, there are some performance hits when using hidden directories, but that is generally only around 4-5% and, since use of hidden is defaulted to FALSE anyway, it stands to reason that the cost outweighs the benefits.

At least with this one, I’ll be able to override the issues I have.

Finally, there is a conceptual difficulty which has come up. There are times when I wish for objects, apart from the controller, to have access to everything which the controller has access to (natively, not with =& get_instance()). Strike that. I think that the controller is not optimal.

The problem with the controller is that it is often asked to do too much. Realistically, it should not really be responsible for the computations which control the site. It is laid out as something which is supposed to call library/model/helper functions, and it is supposed to tell the loader to load views. That is about it. Anything more advanced than a callback to a form validation is best left somewhere else (and even there, the controller should be calling some other model/library function) — especially since that means that it will be easier to run tests against the functions.

This leaves some other, interesting issues. First, realistically, the loader should be considered more of a library class. This might mean that there is a need for two separate classes, or it might mean that “Loader” should just become “Library” and “libraries” should be re-dubbed “utilities”. There should be a view class — something which is acted upon, rather than acting. Then, and this is something which I am adding to MY_Loader in the project, there ought to be manager classes.

These would not be Singletons, and they would each have access to the Library through dependency injection. Their job would be not dissimilar from the current controllers, but the major benefit is that since they are not Singletons, they have the ability to exist in a very modular way. This means that you don’t need to have a special, abstract class which your display class would need to inherit in order to have consistent functions (such as session management).

The next question is, “How are they different from libraries then?” I suppose the manager is the most different in that it is, philosophically, a controller (confusing enough?) which has complete access to all of the library tools. Look at all of the libraries which are packaged with CodeIgniter. For the most part, they simply manipulate data given to them by the controller to return the information back to the controller.

I’m talking about small classes which are instantiated, manipulate the site’s state data, perhaps add some additional output to the screen (and here is where a centralized view class would be IMPERATIVE), and then __destruct without having anything else be the wiser. (perhaps this could employ some form of observer/notifier relationship $instance->notify( “I’m ready to die now.”), but it would be superior to what alternative is available to accomplish the same… nothing.

On a side note, I need to figure out how to get color syntax highlighting.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: