Blogging Pubbitch

The other day I set out to put together a Front Controller in PHP. The good news: it was stupidly easy to do. The bad news: it didn't feel "PHP-ish" at all. This is probably because a front controller needs a certain amount of supporting baggage, such as some way to configure it. A page controller suffers far less from this problem.

Taking a step back, why would a front controller be used? The pithy answer is that it allows the developer to reuse chunks of code as simply as possible. In Java, there's an architectural impetus to avoid using page controllers, since that generally means putting more logic than necessary into, say, a JSP page. But there's no such pressure in PHP because of the nature of the language.

The "PHP-ish" way of doing things involves putting the common logic in include files, and then referecing them as needed before churing out the page. In order to establish a strong separation of view from controller, it might be adventageous to use something like Smarty for the view, but there's no reason not to use PHP all the way through (indeed, Smarty "compiles down" to PHP)

So, it looks like I was wrong when I said that I might well end up plumping for a front controller. It's a bad fit for the language, and it gets in the way of getting things done. Maybe next time. ;)

I've started putting together the code that will form the basis for my next set of articles for .Net magazine. The articles will focus on exploring the MVC pattern and will ultimately lead to the creation of a calendar application (because the world needs more of these)

One of the early design choices is to decide how the controller will be implemented. Coming from a Java background, it would natural to try and apply the pattern I've seen in WebWork and the J2EE spec, where certain URLs are handled by a central dispatcher which delegates to specific actions, the results of which are forwarded to the expected view (the Front Controller pattern) However, PHP applications are normally coded with a series of individual pages interacting with the model (the Page Controller pattern)

For the sake of providing a clearer demonstration of how a controller works, I might well end up plumping for a basic front controller based framework. Things are made slightly easier by Apache's content negotiation facilities (especially MultiViews) which provide a simple mechanism to route non-existant file requests to a central handler. For the sake of completeness, I should also probably add a handler for when MultiViews aren't available or activated (such as when the user insists on using IIS)

This should be interesting. For me, at least. I'll try and develop it using a TDD approach and see how far I get today.

Note to self: when hacking PHP, always check the PEAR first. Just spent a constructive half hour rooting through it and found a cornucopia of handy bits and pieces, including classes for handling config files (yay!), caching and XML-RPC (which appears to be a rewrite of this to PEAR standards)

This could have saved an enormous amount of time. Oh well. *shrugs*