Fed Up with All This Messy Code
Time for Code Review… It’s Christmas
Coding in PHP is dead easy. Any 3-year-old kid can play with it and connect to a database and display data. Coding in a clean manner is a totally different story. The problem is obviously not a PHP-related problem since it has been a conundrum since the developer is a developer. However, PHP, as any script-like language makes messy coding straightforward, not to say a rule. I’ve been taking a look to the code I’ve written in the past weeks because of my recent experience with Spip – of which I will talk below – and geez, how awful that is. Here’s me, preaching all around the place: “Don’t tie application logic and its presentation together or thou shall roast in hell in terrible pains, you crappy crap thing!” and as soon as I open any editor to type in some PHP code, I just don’t care anymore.
Why a Template Engine?
But those recent discoveries about my way of coding in PHP led me to nose around for some proper answer. I’m a big fan of templating because I think it is the answer to the eternal problem of developers and designers working hand-in-hand together. Developers don’t give a damn about design (I’m a bit ashamed to say I’m amongst those ones: when I code something at work, I really don’t bother about the look since there is someone in charge for that) and don’t want to have anything with HMTL, and designers can’t read (and don’t want to) any line of code. The results are sometimes dreadful: the styles are either not applied anymore or modified in an ugly way, or the code doesn’t work anymore becausethe designer deleted some code without realising it. Time lost, time lost and time lost (yes, thrice).
Tough Times with Spip
Those thoughts about my own code were inspired by another programme, though: Spip. On the road to W3C validation, Spip is always on the way. Spip has in fact its own template engine to generate the pages of a site. So far, so good. Except that:
- Spip still produces HMTL tags on the application logic side, tieing together presentation and contents. Those tags include old tags such as <br> (without /), <font> (yuuuuuk).
- Spip template engine is really straightforward, not to say simplistic. The aim is to provide the webmaster with a reduced but easily-usable Spip tags. One drawback of this is that anyone willing to extend this template with his own functions just suffers, bigtime. Another problem which, at first glance, mightn’t look that bad, is that those tags are in French, with no way to customize them since they are hard-coded. Which makes of Spip a franco-français tool, even though documentation has been translated.
- Spip administration interface does not use this template engine. And when you take a quick look at the code, you just close the file immediately because it’s just a nightmare. It is impossible to maintain, impossible to improve, impossible to extend. Well, it is, of course, but it would be a real pain in the ass, because functions are just written anywhere, sometimes several times and the presentation (with its cornucopia of <font> sigh) is scattered in different files, amongst the request processing lines of code. As a result, you just cannot customize the administration interface. Maybe that’s the goal they were looking for (which would be even worse).
Smarty
This is the bitter analysis which led me to take an insightful glance at my own way of coding. And this brings me to Smarty. I had heard zillions trillions of times of Smarty without really taking a look at it. But I am working at the moment with bBlog, a weblog tool written in PHP, which uses Smarty. The results are terrific: a code which is crystal-clear, easily extensible, easily maintanable. I’ve added my own functions with no pain and customized my pages very easily thanks to Smarty templates. And those pages validate.
Smarty has one strong point: you can call PHP functions within the template. One might say this goes the wrong way on the path to application logic/presentation separation. But no. There is a a big difference between removing all the code from HMTL and separating application logic and presentation since you still need to process a list of data to display them. This has nothing to do with business logic and yet it requires code which would be closer to presentation layer. That’s why it is an excellent thing that Smarty allows PHP functions calls within the templates.
The drawback is that Smarty is really a big big thing and you have to be patient to master it properly. It is also a bit complicated to put a programme together with it. But you are quickly awarded for using a template engine: you know where to modify what, you can modify your site layout without touching a single character in your application logic code, you can easily add new functions to your site, etc. All the time you’ve “lost” learning how to use it is paid back darn quickly. Today, I really think that there’s no way I could do without it anymore.
