With the benefit of hindsight I want to go over some of the reasons why moving to a framework (or perhaps a better framework) is a great choice for any programmer once they have a grasp on the fundamentals of PHP.
Proper MVC gives method to mayhem
I used to think I got MVC architecture, but it wasn’t until I delved into CI that I started to really understand how its supposed to look and feel, and why the correct structure is so beneficial to an application.
The way that CI is predictably structured means that debugging is almost fun. There is such a distinct pattern of organisation that finding a gremlin is as easy as looking at the URL and going directly to the responsible controller and method. This carries across projects and across developers.
Gone are the days of following breadcrumbs off to some other obscure part of the application (they don’t really exist anymore) – at worst you would find yourself in a library or helper file which is easily tracked down to a predictable location from the controller level (and generally speaking very well documented).
[On the topic of debugging I will give a curteous nod to CI’s error handling capabilities when in development mode as well.]
Reasonable code organisation is imposed on you to an extent that you probably are in the wrong industry if you manage to make a mess of things.
Not to mention models. Sure, I still have some confusion about how to deal with multiple table joins in an elegant way given the supposed “one model per table” rule, but at least now my models are truly simple and truly re-usable without a hint of business logic in sight.
DIY frameworks are for rookies and exceptional cases – probably not so much for you
Don’t kid yourself into thinking that your method is more understandable to an outside person compared to any well established and widely used framework – and save a thought for the next developer who inherits your code!
Ignorance is bliss
Back then, I said:
I was surprised to discover the folder full of procedural helper functions. This is nice in terms of using functions anywhere inside the application, although it does seem a little out of place in an OOP framework. It would be nice to see these converted into classes.
Actually, the helpers are really awesome, extremely useful and they should not be object orientated.
I find particular use in writing helper functions like now_utc(), convert_date(), user_id(), logged_in() and minutes_dropdown(). They are the kinds of things that you use all over your controllers and worrying about object context is an unnecessary barrier to accessing basic information really quickly.
Q: What does this thing do?
A: Find it in the user guide. Also known as Read The Fucking Manual! It is your new BFF.
The documentation is where the answer to your question is at. If it’s part of CI, it’s in the manual, and in something of a rarity this user guide will answer 99% of your questions efficiently.
The libraries and helpers are really really (really) useful
The best thing I can say about the out-of-the-box helpers, config files and libraries in CI is that they do just enough. Over the course of building a handful of applications you will almost certainly call on the majority of the tools in your formidable tool belt, but by the same token you don’t feel overwhelmed at all by the size of the framework’s footprint, or that it does a lot of stuff that you don’t need.
CI elegantly wraps around some of those everyday pain-in-the-ass PHP functions like database, file uploading, image resizing, email, session, cart and caching.
If only to satisfy all the experienced programmers who have pulled out hair over these native PHP features for many-a-year, you should learn how to do these things natively in PHP – and then you can truly admire what this framework has done with them.
3rd party libraries and helpers + community support FTW
Extending CI is so easy, and it won’t break your code. If it does you just peel off the new layer. It’s like building with Lego. That is why alot of people do contribute, and why alot of excellent libraries and helpers exist to save you time and headaches.
I have really barely scratched the surface in this regard, but I have found a couple of libraries to be instant hits in my applications:
Message is a nice little library that I used as the basis of a global user notification system. In my case this means showing messages to the user spanning success, warning, error and notice notifications. It makes use of session flashdata to output the message once to the user before trashing it.
It has some nice pre-bundled “groups” which you can load from the Google CDN such as jQuery UI, and you can of course write your own groups if necessary. For some reason you can’t cleanly set a group to load at the controller level (as opposed to loading individual files which is trivial), but no doubt simply passing an array or some such thing to the view would solve this problem.
Not only is this great in terms of page download times and saved bandwidth, but is very useful for overcoming pesky browser caching, in that the concatenated file will have a new random file name every time it is changed.
What are the drawbacks?
To be fair to the CodeIgniter community I don’t think I am expert enough in the complete framework that I can make criticisms on aspects of it.
Instead I will list some things that are problems on my horizon that, to my knowledge, do not have easy fixes based on my research so far.
Multiple websites with a shared application on a single server
As far as I can tell, it’s quite possible to run multiple websites using a shared application folder with each site having its own front controller, but having unique configurations and different databases for each site might be another matter. The standard database config is designed to specify a single database to be used at a time. What then happens when each site uses its own database and has some distinct configuration options?
Not to mention how might you extend one site controller without affecting others?
It sounds to me like I need to specify which config(s) to load in the front controller, and or use some kind of hook system, without making a mess of things.
Easy user authentication and permissions
In its defence it has been argued that CI lets you determine user permissions and authentication based on your own individual requirements, however it would be nice if at least a 3rd party library really shone in this area, such that user authentication and user permissions could be configured in a consistent way.
There you have it – my one year summary of my CodeIgniter journey. For a relative framework n00b I think my training wheels are definitely off, and my efficiency continues to grow by the month as my experience and back catalogue of code grows.
So if your not using a framework yet, in the immortal words of the Colonel in Stanley Kubrick’s Full Metal Jacket: