Templating engines
August 19th, 2005
I’ve been working on a PHP template engine over the last couple of weeks. As with a lot of things, there are mixed views about templating. I used to advocate not touching them – they’re slower, sometimes restrictive and sometimes make you learn a new language. I just couldn’t see the point. But after working with a few different designers/HTML coders, the clouds started to clear – although some were completely fine with with PHP, some got confused and some even got scared of doing very much at all – I decided that a template engine was the way to go, especially as if you the right one you get free presentation and business logic separation (a Good Thing – use Google if you want an explanation).
Ian Leitch’s post on templating popped up on Gentoo Planet today and he seems as confused as a lot of people are. He points out that templating systems usually go one of two ways – allow a limited set of commands or allow loads of commands. I agree that if you want to enable a lot of commands, you should probably scrap the whole templating thing and give full access to PHP or whatever, although this has a whole new set of considerations. Some people say that if your designer can’t learn PHP you should find a different designer. Unfortunately, in my world, this isn’t always an option. I have to work with a variety of designers/HTML coders and often have no control over who they are. Occasionally, if God is feeling particularly unkind, I have the unparalelled joy of working with HTML dreamweaver table based designers or other such scum. What would you rather these clowns had their hands on – PHP/Ruby/whatever or a limited set of operations of your choosing? In the end, what you use probably depends on circumstance as much as anything else. If you are lucky enough to only work with designers who are comfortable and proficient with your scripting language of choice, then templating gives you far fewer gains than if you have to work with people who you’d rather not give access to the filesystem to. But I still think there are gains to be had.
I looked into some template engines – there are hundreds of them – but couldn’t find one that seemed right (I guess that’s why there are hundreds of them), so decided to write my own. I might write more about my own template engine in another post, but to whet the appetite (or not, as is probably the case) I based my engine on the following:
- Not all designers are stupid and crap with code. But some are.
- The template code should be easy to read and write.
- You should be able to load a template file in a browser (without a web server) and view the placeholders.
- Should be easily maintainable and extensible.
While developing my system, an added bonus has been that I’ve found it way nicer to code templates now than using foreach, echo, etc. This wasn’t really part of the main plan, but it’s lovely that it’s worked out like that. Maybe I’ll write more about it later.
I get the impression that he likes the idea of separating presentation from business logic but that he doesn’t want to restrict what developers can do.
Leave a Reply