Paul Rouke and PRWD on User Centered Design

Following my earlier posts on Zend Framework and Symfony, the final part of my comparison will be an evaluation of Kohana.

Kohana is the newest of the three frameworks, appearing in May 2007 (albeit under a different name). However, Kohana began life as a fork of the CodeIgniter framework. The Kohana developers wanted to take the framework in a new direction, adding support for PHP 5 amongst other things. Now, over a year later, relatively little of the original CI code remains in Kohana.

Features

Having already written two posts about the feature-sets of MVC frameworks, I find that there’s not a lot new to say.  The usual features are in place: Kohana provides a default front controller which dispatches requests to methods of a controller class, located via routing rules.  Unlike Symfony’s YAML approach or Zend Framework’s .ini files, Kohana’s configuration files are all PHP-based, which adds some flexibility.

One particularly nice feature of Kohana’s configuration system is the ‘overriding’ of system-level defaults by application-level replacements.  The Kohana file-system is structured as follows:

<root>
  application/
    config/
    controllers/
    models/
    views/
    ....
  modules/
  system/
    config/
    controllers/
    models/
    views/
    ....

I’ve skipped out some directories from this file structure - the important point is that the structure of the ’system’ tree - which contains the core Kohana files - matches that of the ‘application’ tree.  This provides a useful concept for thinking about your application: it’s all about extending Kohana to do what you want.  A parallel can be drawn with Drupal’s module system, where modules in the ’sites/*/modules’ directory override those in the ‘modules’ directory, and so on.  In many respects, this doesn’t offer any particular advantage over any other approach, but I found that it helped my conceptual thinking.

This ‘override’ approach applies to all files in the application tree, from config files to controllers and views.  The system config files provide sensible defaults, but if you want to change them it’s easy.  Just copy the config file from the system directory to the app directory and start editing.  That the config files are in PHP is especially refreshing - no .ini files, no YAML and (praise be!) no XML!  Although some might argue that this detracts from readability, I disagree: not having to do a mental context-switch to go from reading YAML to reading PHP saves a lot of time and reduces the likelihood of error.

Taking the ‘override’ approach even further is the concept of ‘hooks’ and ‘events’. These will be familiar to many developers coming from other backgrounds; essentially, Kohana allows you to perform actions when events occur within the system. The core system provides some basic events (’startup’, ‘load controller’ and so forth) which can be handled by your own code. There’s nothing particularly revolutionary about this, but Kohana makes it easy to, for example, perform an action each time a page is displayed simply by writing a function and registering it as an event handler. No object-oriented inheritance voodoo, just a simple system that works.

Documentation

Kohana’s core code is readable, generally well-commented and using a good coding style.  And it’s a good thing too, because any Kohana developer will probably find themselves referring back to the source code quite often, owing to the relative lack of documentation.  There’s a valiant effort at creating some Kohana tutorials underway, but there’s a long way to go before Kohana’s docs can compare to Symfony’s. From a developer’s perspective, this makes using Kohana fun; it’s obvious that the developers haven’t made any particularly stupid blunders in designing the software and have succeeded in producing a very nice, elegant codebase. But there can be frustratingly few good examples of its use around, and the ‘community, not company-driven’ ethos can leave Kohana’s documentation and support materials looking a little unpolished compared to others.

Community

Kohana’s community looks strong and enthusiastic, driven by a genuine desire on the part of the participants to build a genuinely good framework. It’s hard to explain this in detail, but it’s possible to sense the desire of the developers to create something that is, in its own way, a work of code-as-art. The Kohana community is, of course, only a little over a year old. There isn’t yet a major book on Kohana and there are relatively few blogs about it. But there’s enough action at the core to suggest that Kohana can be sustained for the long term.

Conclusion

Kohana has much to recommend it. It’s evidently well-coded, with plenty of intelligent ideas behind its design, and a vibrant community. But, on the down-side, the documentation is severely lacking and many of the ‘jump-start’ features of other frameworks - say, basic CRUD code generation - aren’t present. This adds a little steepness to the learning curve, although I have to admit that I really enjoyed getting my hands dirty with Kohana. One regret is that there seems to be no central repository for Kohana modules (equivalent of plugins in Symfony). Being able to grab some ready-made modules to solve common problems would be nice.

My overall sense of that Kohana is that it probably will be the best PHP framework at some point in the future. It’s clear that what the Kohana community is building is something big and ambitious that might, one day, be the best way of rapidly developing PHP applications. But the shortcomings can’t be ignored: lack of documentation and lack of modules mean that there are other frameworks that can get the same job done faster. If you’re embarking on a long-term project and are not scared of using the code and comments as your primary documentation, Kohana is a great choice.