Almost any web-based application today will do this: it will collect information from a database, merge that information into prepared page layouts and then send the result to the user’s browser. The problem is how to do that merging of data and presentation (the page layout). It’s problematic’ not because it is impossible, in fact there are an abundance of libraries and systems to do it, but because it is a conceptual mess that invariably merges coding inside HTML layout. Some examples will demonstrate… So here is a typical templating approach using the common PHP language. The web page that is sent back to the user is a HTML page with some PHP programming instructions inside to add in data. Here is your data There were no rows found. Many libraries try to untangle this mess, for example using the popular Smarty templating system re-writes the example as Here is your data{foreach \$foo as \$bar} {\$bar.zag} {\$bar.zag2} {\$bar.zag3}{foreachelse} There were no rows found.{/foreach} This really isn’t an improvement, it’s just substituting another (supposedly easier to learn) syntax and not addressing the underlying problem of mixing layout instructions (the HTML) and coding. This problem is not confined to PHP or Smarty or any other system. ASP and JSP all follow the same pattern. If you want further evidence that this is a faulty approach consider who will edit this template. Should it be the designer? They will load it into Dreamweaver and (in my experience anyway) promptly destroy the embedded code. Should the developer edit it? Sure they fix the code but they aren’t known for their design and layout skills. This failure to separate the two concerns of logic and presentation creates messy and hard to maintain systems. So what’s the solution? Imagine a template with no coding, just named elements Here is your datathe data goes in here This template is XHTML compliant and is fully the preserve of the designer. Code (the preserve of the developer) can identify that id=”TEMPLATE.DATA” and replace it with appropriate XHTML. If we are smart enough to fetch our data from the database as XML then it’s as simple as applying a basic XSLT transform to the data and manipulating the XML of the template to insert it. I’m using this technique for a client who had got into a tangle with templates and embedded ASP code. I looked at a variety of solutions but all seemed to suffer from the same tangling of code and presentation. My system creates a strong separation between the templates, code and database. In some ways it’s not simpler but the complete separation is where I hope to win. It’s simpler where the client interacts with their site. Obviously there is a little more to the technicals but it’s proprietary at the moment so I can’t splurge source-code. The real test comes when we see if the client gets the idea and can begin to make site changes quickly and confidently.