[Quick Tip] Add Composer Dependency Manager Support To Kohana

Composer is a super cool way to manage dependencies for your applications. Kohana’s autoloader does not support Composer’s way of autoloading, so if you’re wanting to use composer packages in your application you’re going to run into issues.

However, it’s really really simple to add support. Simply open your application/bootstrap.php file, and (I added this after Kohana registered its autoloader) add

require [FULL_PATH_TO_COMPOSER_FOLDER].’autoload.php’;

Where, of course, [FULL_PATH_TO_COMPOSER_FOLDER] is the actual absolute path to Composer’s auto-generated auto-loader files.

Voila! You should now have Composer support in your Kohana app! 🙂


Kohana 3 & CodeIgniter 2

For the last month or so I’ve been developing an app side-by-side with Kohana 3 and CodeIgniter 2 to see which framework fits my programming style better. Nothing terribly fancy; just a simple CMS.

I’ve been using frameworks to develop since 2006, back around CI 1.5.x. The differences between CI 1.7.x (the latest version as of this post) and CI 2.0 are negligible. My biggest nitpick comes with the helpers. I’m lazy and I’m also somewhat speed-conscious, which means I either need to autoload all the helpers my app needs in the autoload.php file (or early in my app) to appease my laziness, or load them as needed to appease my speed-consciousness. It irritates me that they’re basically files holding groups of procedural functions and if I want to access the CI super global I have to instantiate it in every function.

I started dabbling with Kohana a couple of years ago, in the 2.3.x era. I really loved their use of static functions (I’d only had basic OOP experience at the point), but I just never felt comfortable with the way things changed so much between versions. Last year when v3 was announced I had a look through the code and said “forget it”. But eventually I became curious again and started learning it to see how easy/hard it was to develop with it. I personally did not have a lot of trouble learning Kohana 3, between the user guide and the unofficial wiki. Perhaps my biggest stumbling block came with the Database module, which was a complete change from any of the v2.x database classes.

I really didn’t find either framework harder than the other to code for. I was able to more or less figure out how to do what I wanted to do in both. Yes, Kohana’s docs suck and CI’s are much better. For me it wasn’t much of an issue.

In the end it comes down to framework stability for me. And in this case, CI wins, hands down. Don’t get me wrong; Kohana is beautifully written and introduced me to a prime example of clean, well commented code. The devs are extremely intelligent and more talented than I’ll probably ever be. CI is also very clean, though there’s a bit more hacking involved for me to get it to work the way I like. However, I don’t want to be writing my own clean, well-commented code for one version of a framework only to find out the next version is going to totally break backwards compatibility. The lead Kohana devs have stated that there are no guarantees of stability between major versions (ie 1.x-2.x, etc). Comments like “well if it ain’t broke, don’t fix it” are dandy, but if part of the reason I’m using a framework is to let someone else worry about the basics for me, why would I stick with something that is no longer actively developed because the devs are on version 342.x?

While I respect progress and not letting code stagnate there’s something to be said for code stability when you’re maintaining a framework. Uber-optimising something is great (as there are repeated mentions of “x function is faster than w function” in the Kohana forums) but if it’s only saving me 0.02 ms of page load time or 0.25 mb memory, I’m not sure unstable code is worth that bit of extra speed. Furthermore, using an older codebase when you’re a one-(wo)man show can be a nightmare, since it’s a lot easier for one person to miss something than two, whether it’s a simple invalid method call or a glaring security hole.

I want to create apps to earn a living and I want to know that my code will stay more or less relevant between framework versions. API changes are to be expected between versions but complete rewrites, with very little thought for BC is just poor project management, IMO.

Please bear in mind that these are simply my views on the frameworks and my experiences and since I’m not a BDFL PHP guru (or something), you should perform your own research to see what works for you.

Update: I’ve posted a follow up post with some more thoughts (and such): https://nerdmom.wordpress.com/2010/08/31/a-follow-up-on-kohana-3-codeigniter-2-the-flip-side/

Why is it so hard to make a choice?!

So I’ve been working on OMGSUPERAWESOME© idea for almost 2 months now. I wrote initially about how I was using Kohana, then started trying out CakePHP and CodeIgniter when I saw that the chances of Kohana’s 3.x codebase being compatible with 2.x were slim to null (heh – I love programming humor :))

I also have been dabbling a mite in Zend Framework, which, I have to say, I find really complicated but also kind of interesting (although the interesting may due to it being a new framework). I’m a bit wary of it, though, since a very simple query to retrieve 3 rows from the database usually gives me a benchmark of .2 – 1.2, whereis in CodeIgniter I’d get a .01 – .3 and Kohana, a .01 – .8.

I think I will probably end up returning to Kohana because the framework just feels right — I feel like it gives me what I need to help me code faster AND better, while allowing me to do the things I want to do. ZF feels like it would end up being way too much for this project and it just doesn’t feel right to me the way Kohana does. And you know, I would have probably stuck with Code Igniter if I didn’t feel like it was 2x as much work to get certain things accomplished (vague, I know; perhaps a topic for another post).

My biggest concern with Kohana is the compatibility between version issues. However, I did read that v3 will likely not be out until mid to late summer this year, so I suppose we’ll just have to wait and see for now.

Frameworks Part Trois (or, Sometimes when you're right, you're wrong)

Yesterday I posted about my experience trying out CI, Cake, and Kohana side by side while I work on my super-cool-blah-blah-blah idea. I mentioned how I was unable to retrieve lists of things with Cake and Kohana, and how quickly I got through things using CI + DataMapper.

Well, Houston, we hit a problem.

Last night I realized that DM was not encoding passwords before inserting/updating them in the database. I ended up changing it to just encode the posted password value and insert (not an ideal solution, IMO). This morning I was making a few other changes and running some tests and I realized something huge.

DM was not validating any of the data.

Obviously, this is a HUGE concern, and not one I was particularly interested in trying to track down and fix. On a whim I decided to give Kohana one more try, and holy [expletive] am I glad I did.

I have no idea what I was doing wrong yesterday with the ORM library but today it’s been working flawlessly (knock wood). It’s validating things the way it should, inserting and updating the way it should, and (hopefully) will help maintain the relationships the way it should.

As far as the rest of the functions and such, it was extremely easy to switch things from CI to Kohana (the fact that I’m only about 4 files in helps ;)). I’ve been able to find/figure out pretty much everything from the docs on their site and a little googling.

At this point, assuming the ORM continues working the way it should, I feel pretty good that I’ll finish up this project with Kohana.

Side note: I found a module at projects.kohanaphp.com that’s called “Debug Toolbar” and it’s pretty sweet. It shows execution time, memory consumption, all db queries, and other nerdy goodies for the developer to use. It sits at the top of the browser, out of the way, and is slightly transparent. Cool stuff!

php frameworks – my opinion

I heart PHP. I’ve been working with it in one form or another for over 8 years — back in the PHP 3 days, even! I’m entirely self-taught, relying on php.net and tutorials to help me figure out how to do stuff.

Last fall I was working on a niche-oriented CMS and was getting majorly bored/burned out by all the procedural stuff; the code felt horribly messy to me and I wanted to get into OOP (Object Oriented Programming) but previous attempts had left me scratching my head.

Somehow I stumbled on CodeIgniter and I was immediately hooked. Once I figured out my way around MVC and their way of doing things I tripled the amount of code I was able to put out. Was my code the best you could ever find? No, but it was definitely a step ahead of where I’d been.

Once I finished the CMS I decided to tackle another project and turned again to CI. I’ve been working on this project for the majority of 2008, and might have it done by the end of the year.

Now, I really love CI because it’s so easy and flexible, and it’s pretty much agreed that they have the easiest to understand documentation. However, I began to get frustrated with some of the features the default CI lacks – Auth being the biggest — so I started “shopping around” some other popular frameworks. Following are the ones I dabbled with. Note that there are no benchmarks because frankly that wasn’t my concern — realtive ease of use and the speeding up of my development were the primary concerns was.

Zend Framework – http://framework.zend.com:
Impression: After Symfony, I say ZF is probably the daddy of the frameworks. You can develop some really powerful stuff with it. That said, I found it to have a really steep learning curve and to be too loosely coupled for my taste. Requires more manual configuration than most other frameworks. It took me almost a full day to figure out the Zend_Db class and even then I wasn’t able to move too far with it. I was really impressed with their ACL and Auth classes, although I didn’t get far enough to really dabble with them.
Conclusion: If I had more time to play with it, I’m sure I could figure ZF out and develop some really cool stuff. For now, I will most likely stick with implementing components of ZF with other frameworks.

CakePHP – http://www.cakephp.org
Impression: One of the most popular frameworks. Pretty strict with naming conventions. Models are a must (this is not a bad thing). I actually played with this for a couple of days and got a lot farther with it than I did with ZF. The docs (2.2) are pretty good and I was able to find almost everything I needed to know within them. Because it’s so popular, finding things that weren’t in the docs — like a form tutorial — was really easy.

Conclusion: I may go back and try my hand developing something with Cake. If you have moderate experience with MVC, it’s not (IMO) that hard to learn. It’s a lot slower than pretty much any other framework but it also does a lot of stuff for you that could speed up your production.

KohanaPHP – http://www.kohanaphp.com
Impression: Kohana is a relative newcomer to the PHP Framework scene; it originated as a fork of CI when a bunch of CI developers got tired of waiting for EllisLab (creators of CI) to fix bugs with CI. Right now the current release is 2.2 (I think) and while a lot of things are different from CI, it’s still feasible to port CI apps to Kohana by renaming a few things and following some different rules, like using helper::helper_function instead of $this->load->helper(‘helper’) and helper_function(). I wasn’t very impressed with their docs; I found reference to the “Forge” class, that helps consolidate form creating/validation rules, only to find out Forge has been depreceated in Kohana 2.2.
However, Kohana does seem very powerful and I don’t think it would be too big of a leap to go from CI to Kohana. I really like that they have an advanced archive class as well as auth and payment modules.

Conclusion: I will probably use Kohana at some point; I may even recode the 2nd draft of my current project in Kohana since it provides more built-in functionality than CI does. I really like that it is community based; however, from what I’ve read the framework seems to depreceate things fairly often, which could make developing with it a pain in the ass.

CodeIgniter – http://www.codeigniter.com
Impression: As I said, I love CI. It was so easy to learn and really helped speed up my PHP production. The community is awesome, the docs are awesome, and it’s so flexible I can do pretty much anything I want with it. The “bare-bones-ness” of it, though, is also frustrating at times, especially when I have to manually code something in that the other frameworks provide by default — again, mainly Auth stuff. I think it’s kind of neat that it’s used and backed by a company (EllisLab, which produces the Expression Engine commercial CMS), which should provide security as far as it being around. The bad thing about that is that since it’s developed and maintained by a company, fixes to bugs and other issues can take a lot longer than a community driven framework. I’d really like to see CI get into module-type stuff or at least include company-supported libraries like auth and payment.

Conclusion: I will likely stay with CI for now; when I get more time to dabble with Kohana more it will become more of a competition in my mind. I have to say, though, that for each (hee!) framework I tried, I ended up going back to CI with relief mostly for its flexibility. That could just be due to my being most familiar with CI, though.

To wrap it up, my choices would likely go like so:

  1. CodeIgniter
  2. Kohana
  3. CakePHP
  4. Zend Framework

I know that this hasn’t been a very “techy” type of comparison; as the title suggests, these are merely my opinions on the 4 frameworks I’ve tried out. Eveyrone has one that clicks for them, and you’re definitely entitled to use that one and call it the best (for you!).