The problem with template systems
Brian Lozier offers some interesting remarks about Smarty and the use of PHP in templates:
Why do I say Smarty has it closest to right? Simply stated, because Smarty’s goal is “the separation of business logic from presentation,” not “separation of PHP code from HTML code.” While this seems like a small distinction, it is one that’s very important. The ultimate goals of template engines shouldn’t really be to remove all logic from HTML. It should be to separate presentation logic from business logic.
There are plenty of cases where you simply need logic to display your data correctly. For instance, say your business logic is to retrieve a list of users in your database. Your presentation logic would be to display the user list in 3 columns. It would be silly to modify the user list function to return 3 arrays. After all, it shouldn’t be concerned with what’s going to happen to the data. Without some sort of logic in your template file, that’s exactly what you would have to do.
While Smarty gets it right in that sense (it allows you to harness pretty much every aspect of PHP), there are still some problems. Basically, it just provides an interface to PHP with new syntax. When stated like that, it seems sort of silly. Is it actually more simple to write {foreach –args} than < ? foreach --args ?>? If you do think it’s simpler, consider this. Is it so much simpler that there is value in including a huge template library to get that separation? Granted, Smarty offers many other great features (caching, for instance), but it seems like the same benefits could be gained without the huge overhead of including the Smarty class libraries.
I’m basically advocating a “template engine” that uses PHP code as it’s native scripting language. I know, this has been done before. When I read about it, I thought simply, “what’s the point?” After examining my co-worker’s argument and implementing a template system that uses straight PHP code, but still achieves the ultimate goal of separation of business logic from presentation logic (and in 40 lines of code!), I have realized the advantages and honestly, can probably never go back.
While I think this method is far superior, there are of course some issues. The first argument against such a system (well, the first argument I would expect) is that PHP code is too complex, and that designers shouldn’t be bothered with learning PHP. In fact, PHP code is just as simple (if not more so) as the syntax of the more advanced template engines (such as Smarty). Also, you can use PHP short-hand like this: < ?=$var;?>. Honestly, is that any more complex than {$var}? Sure, it’s a few characters shorter, but if you can get used to it, you get all the power of PHP without all the overhead of parsing a template file.
The examples he gives makes it look like his system is similar to my system, though he uses object oriented code, whereas I’ve given up on OO and gone back to simple functions. He’s also using more PHP in his templates than what I’m used to seeing, but I’m open to that approach.
The only problem with his article, and with this weblog post, is that we are not hearing from the people who actually have to use these template systems – the designers. Their opinion should carry the day, in the end, about what template system is best. I hope to post more about that soon.
I’ve used a php/oop system for years. I wouldn’t change it at this point. Something about Smarty just bugs me. Using PHP just works. As far as getting designers to work with it though is an issue. But if it’s just simple print/echo calls and an occasional helper method than no problem. If you check out the Solar/Zend helper system, you’ll see that it is possible to remove all logic/loops from templates and still use PHP in a sane manner. It’s the difference between this:
user->loggedIn() ) { ?>
Welcome, user->name() ?>
// display form, errors etc.
And this:
showLogin() ?>
If the showLogin() output needs to be changed, just go to the helper class and change it. The helper could sill implement templates. And those templates could be more fine grained. Then the designers could get in and change it. But getting too fine grained in the templates is risky too.
Even people in the Rails community put html in ruby code, in their helpers. It’s about finding a balance between control and maintainability. I think the holy grail is in the eye of the beholder.
“Even people in the Rails community put html in ruby code, in their helpers.”
But surely there are only particular situations where Ruby On Rails is the ideal framework? In the very near future we plan to start using Ruby On Rails here at Category 4, but we won’t use it for simple sites. What would be the point? It was originally developed to help produce Basecamp, and it remains optimized for sites that are mostly software, rather than informational files.
“I think the holy grail is in the eye of the beholder.”
I agree there is no one ideal for all web sites, but I think for particular categories of sites we can define what the ideal would be. We could, if we wished, make a list of every good thing we could possibly associate with a web site: performance, maintainability, extendable, modular, easy to understand for users, easy to understand for programmers, intuitive structure, easy to design for, etc. We could make a long list. Out of that list, we could probably pick 3 things that must take top priority, either for the firm we work for, or for us as individuals. Given those 3 attributes, we could probably define a ‘holy grail’, a framework of perfection for those 3 things.
What I’m trying to say is, once we narrow down what attributes we really need from a framework, I don’t think selecting the best framework would be quite as subjective as what you seem to be suggesting. I could always be wrong, of course, but I think for a given task we could use fairly objective metrics to determine the best framework.