I’ve used Ruby for scripting, and deploying PHP applications with custom Capistrano recipes for years now, but I’ve never tried any of the available web frameworks.

This week I switched to Ruby on Rails, and I’ve accomplished more in a couple of days than in a couple of months with CodeIgniter.

I’m not trying to claim that there’s anything fundamentally wrong with PHP, so don’t beat me up over it, but I find working with Ruby and Java much more intuitive, enjoyable and productive: it’s a personal choice, I feel more inspired.

I’m particularly loving the default support for unit, functional and integration testing; I now feel in control of my code and I’ve yet to explore the full range of testing frameworks and approaches available for Rails.

I know that CakePHP mirrors Rails functionality very closely, but I’m afraid it’s the PHP language that I find too ugly to love – personal choice again, don’t shoot – consequently this is one developer who may have written his last line of PHP code…… maybe.

I’m now hoping to have the first release of the nature and wildlife recording application I’ve been promising Clare for…… much too long, up and running in the next couple of weeks.

Positive experiences.

The most frequently touted benefit frameworks have to offer is minimising the time taken to code and deploy a software solution. Given my interest in Agility, this is an attraction, reducing the time to market.

Another solid development practice is code reuse in the form of software components, and frameworks have a place amongst them. This approach offers the reliability and security inherent in widely used and tested code. Remember to choose popular software though, or this benefit disappears.

On the downside.

Applications developed using frameworks have to carry significant excess baggage in the form of unused features. This raises two main issues: your codebase will be unnecessarily large, and underused blocks of code are a breeding ground for hidden exploits and errors.

Frameworks are designed to function in a specific way, some with more flexibility than others. This much you’d expect, after all it’s the essence of a framework, but what if it doesn’t provide everything you need? For example, I’ve spent hours trying to integrate SimpleTest, a unit testing suite, to produce satisfactory results with CodeIgniter. My unit tests run well for my own libraries, but I’m still unhappy with the test coverage imposed by CodeIgniter’s MVC implementation.

Finally, they say practice makes perfect, but does reliance on any framework reduce developer skill? This isn’t a problem if everything is pre-packaged in your chosen tool, but what if a client wants something that isn’t included?

Too good to ignore.

That said, I’ve found all of these software very useful and there are far too many advantages to ignore them. But I often find myself fighting these same tools, frustrated at they’re eagerness to help me do something in a way I don’t want it done. I guess the key is to understand which is the right tool for the current job: the ultimate skill for a developer.

Changing the Architecture.

I’m not a keen on the idea of dumping all my code in the web server root directory, so I tested the framework flexibility by rearranged the application structure a little.

	-rw-r--r--   1 Capfile
	drwxr-xr-x  14 application
	drwxr-xr-x   3 config
	drwxr-xr-x  13 system
	drwxr-xr-x   5 public

Once these locations were updated in the application configuration files it all worked perfectly. The reasons for doing this sort of thing have been documented elsewhere, and I agreed with them from this security standpoint, however this structure also fits better with Capistrano deployment.

A positive first impression.

The Views deal with the presentation logic, and I like the fact that embedding PHP within the HTML is the default, instead of a complex templating system. It’s not the cleanest approach, but I prefer to have full control over my HTML.

As for the Controllers, the implementation is quite intuitive and you can build a friendly set of URLs with a little help from mod_rewrite and the URI class.

The form validation is a great feature that I found easy to implement within the Controllers and Views. I’ve centralised my validation rules in the global configuration file suggested in the documentation, but haven’t got the automatic rule group feature to work yet.

The Model class is used to represent a single database table. I’m used to mapping tables with a Class in this way, but normally each instance would represent a row of data. CodeIgniter Models implement the Singleton design pattern, only one instance per class, from which the Database class methods can be called.

The Database class provides the data access layer and a good set of robust methods which return an array of stdClass instances representing the resulting data rows. These arrays are then forwarded to the View, where the instance variables can be directly accessed. This is quick and easy, but not very OOP.

Implementation reservations.

I believe that the Model should be capable of running as a stand-alone application, once equipped with any interface, even the command-line. It’s this level of autonomy that results from the MVC design pattern: substitute a different Controller and View and it’ll still work the same way on a different platform.

Controllers reacting to events, whilst Views shouldn’t have direct, mutable access to instance variables. The Model should encapsulate both the data and the business logic, not something that can be effectively achieved with Singletons alone. Indeed CodeIgniter blurs this distinction by making Models optional and allowing data manipulation directly in the Controllers.

I’ve implemented my preferred approach by providing my own classes to replace the stdClass. They don’t extend the CodeIgniter Model class, but are instantiated within those that do, encapsulating data and business logic; including Object–relational data mapping and CRUD functionality.

It works well, but I’m concerned that by introducing a more rigourous approach I’m losing some of the advantages of the framework. May be I would be better to take CodeIgniter at face value, as a flexible, if a little dirty, rapid development environment that works.