Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /share/CACHEDEV1_DATA/Web/www/libraries/UBBcode/text_parser.class.php on line 228

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /share/CACHEDEV1_DATA/Web/www/libraries/UBBcode/text_parser.class.php on line 228
Template engines: friend or foe?

Comments Blog About Development Research Sites

Template engines
Friend or foe?

Dec 11, 2007
It seems like every odd month a new discussion erupts at a forum I frequent about the use of template engines. It would seem it's a discussion without end, with fierce defenders on both sides. So, in the spirit of everything web 2.0, my thoughts on the subject ;)

To start of, I only really 'know' one good template engine: Smarty. It has almost all the functionality you need and is easily extendable to provide the rest as well. You can register dynamic blocks, create your own plugins, etc. This allowed me and my collegues to tailor it exactly to our needs without really all that much effort.

Maybe a little more explanation is required at this point. What Smarty allows us to do is add dynamic components to an otherwise ordinary HTML page, like this:
Code (php) (nieuw venster):
1
2
3
4
5
6
7
8
9
10
<html>
  <
head>
    <
title>
      {
tr id=pageTitle}
    <
/title>
  <
/head>
  <
body>
    Hello world, {$name}!
  <
/body>
<
/html>
This is quite a plain example but I think the general idea comes over: just an ordinary HTML page such as even designers can comprehend, with here and there a touch of strange tags. The first one is a plugin we wrote ourselfs: {tr id=pageTitle}. What this little gem does is look for an entry 'pageTitle' in our translation database and translates it in the language selected by the user. In other words, instead of putting text in HTML / template files we can simply put it in a CMS system and have it automatically translated, without having to make several copies of our templates!

The next tag is even easier: {$name}. This is a normally assigned variable. Were this a PHP template I could also have written . Some argue that PHP can in fact do everything Smarty can, and the only 'real' difference is a few extra characters here and there. They are absolutely correct in that first aspect: since Smarty internally compiles templates into PHP files its limitations are exactly the same as that of normal PHP templates, and we get no 'new' functionality. The second point however is not so valid: yes, smarty can make your echo's a bit shorter, but that's only the start! I have already shown how a translation plugin is easily integrated, lets compare that with the PHP way:
Code (php) (nieuw venster):
1
2
3
<title>
   echo Messages::translate('pageTitle'); ?>

Already we see the PHP way is over twice as long! Now, in itself this is no disaster, but with big templates imagine the amount of typing you save and the amount of needless clutter you can prevent! Not to mention the fact that if you ever, for some reason, want to change the function that translates for you (to require an additional parameter for example) you'll have to change all your templates - instead of just changing the smarty registration call!

Now one might again argue that all this is fine, but that it's still overhead of sorts and thus slows down the page. To those I like to suggest taking a look at the parsetime at the bottom left of your screen: the archived pages on my blog are partially cached, so if you go to an archived item which isn't cached you'll see something along the lines of '0.143s - 5 queries were made'. Refresh the page and you'll see the parsetime has actually decreased to 0.05 and only 1 query is made! This is because Smarty lets me register certain blocks on the page as cachable and it automatically stores a copy of those blocks in HTML format!

Once again, this is nothing 'new', nor could you not do the same with PHP templates. But ask yourself the question: would you do it with your PHP templates? Or would you consider building a caching engine and writing special functions in your pagehandler for turning parts of your site into static caches too much effort? I think we all know the answer to that one ;)

For those still not convinced: the 'real' argument for template engines in general: they're not as advanced as PHP. At first glance it might seem I'm switching sides here, but think about it: your template is for display logic only! There is nothing so twisted in a dataset that a few foreach and if statements can't fix, but if you want to do that in a template you'll soon find yourself rewriting your data logic to produce easier to handle datasets because of the limitations you find yourself in! I actually once rewrote a 20 line SQL query with the most horrible result ever that did, in fact, contain all the data I needed, into 2 quite elegant little queries that produced the same result only organised and ordered in such a way I could actually output it in a single loop. As a sideeffect, when a few weeks later I needed that same dataset I saved a lot of time by just calling that old function again since it was so easy to use!

To summarise: a really good template engine makes sure you have less (PHP) clutter in your templates making them easier to change, provides an easy interface for caching results making it easier to render parts of your site static thus saving greatly in execution times and most importantly force you to actively think about where you organise your data - and makes sure the answer is always 'anywhere but in my output logic'!

Of course even I have to admit there is a flaw in using them: they're resource hogs. Smarty is pretty well setup, but even so there's a lot more lines of code your parser has to get trough to produce output. Part of this is of course because its such an extensive engine with loads of debugging stuff available and nifty functionality you might rarely use. If you find yourself on a newly created development team with a stash of cash and spare time, it might be worth looking into writing your own template engine - we did the same for our framework and I'm not regretting those weeks we spend on perfecting that for a second :-)

FragFrog out!

New comment

Your name:
Comment: