Where I'm coming from

De gustibus non est disputandum

It is often said of template systems that they are mostly a matter of taste. While I think there are important functional differences that this glosses over, it's true that the "feel" of template systems has a big impact on how people relate to them. With this in mind, I'll give a little bit of my own background and taste in template systems, since this will inevitably color my perception of the systems I try out.

It's real hard work

My day job involves working in web development at a major eCommerce company. We release a new version of our web site every month, more or less in conjunction with a snail mail catalog. Most of my time is spent working on the presentation logic, interfacing the back end with the front end. At my company we use our own internally developed templating system. This involves, for the most part, tagging chunks of HTML for replacement (inside simple HTML comments), and then replacing them mostly by building up the replacement HTML in code and, as a final operation, dropping it into the slots we've tagged in the original HTML.

Far be it from me to claim that this is the best template system possible; one of its unfortunate side-effects is that the final HTML tends to be split up among the original source files and various bits of code. However, it does have the advantage of simplicity, and more importantly it fits our business workflow pretty well.

Said workflow generally goes like this. The business develops the requirements for the month's release. The creative department comes up with composites of the various pages, most often in the form of TIFFs. These get handed off to the production team, who must then produce HTML which matches the comps pixel for pixel. They hand this HTML off to me. I tag parts of it for dynamic replacement and then write the necessary code to pull in various dynamic elements from the back end.

Implications

With that in mind, let me point out some of the implications this has on how well different templating approaches would work if they replaced this system (about which, unfortunately, they are not going to replace anything wrt my day job).

I don't own the HTML.

I don't create it in the first place, and if it needs to be modified, either during the QA cycle of a new release, or as a bug fix or enhancement of old code, it's not my responsibility to modify it. Which, frankly, is a relief, because:

The HTML is very robust.

As an eCommerce site, we need to make sure that as many people as possible can view our site correctly. This includes people with terribly old browsers, people without javascript turned on, and so forth. Even the infuriating Netcape 4.x users who apparently surf the web just to make things hard on the rest of us must be served legible, functional HTML when they visit our site.

One important consequence of this is that the HTML is also very complex, full of nested tables, spacer images, and the like. Our production team is made up of very skilled HTML folks who are mandated to reproduce TIFF images down to the pixel. While I'm sure they (and I) would love to use fancy table-free CSS-style positioning, browser support for it is not widespread enough among our user baseto be reliable, and in the business we're in, one can't afford to lose users over high-minded idealism about web standards.

What it all means

Given the complexity of the HTML, and the fact that I don't maintain it, there are some prejudices that I'm going to bring to template systems. The most important one of these is that my preference is for the template commands to be invisible in the html itself. That is to say, once Production has given me a page of HTML, I want to be able to tag it so it becomes dynamic, and then hand it back to them, so that if they need to change the layout and so on, they can do so and as long as they leave my tags alone they'll be fine.

If my markup is invisible, that's fine. But Production is generally going to have a tough time creating pixel-accurate pages if there are plain-text #cheetah-directives all over the place in the HTML itself. (I'm using Cheetah as an example here after just taking a cursory look at it, for all I know it has a way to embed the directives in a comment or something, so the directives are not rendered when one just pulls up the HTML in a browser).

At any rate, to start with I'm going to focus on template systems which are are able to work without causing any visible deformations in the HTML they are applied to.

There is lots more I could say about this, but I'll leave it there for now. Hopefully that gives a good impression of what my approach is going to be.

I should also note in passing that this certainly not the only valid approach to template system evaluation. On many small or non-commercial sites the UI does not need to be as specific as it does where I work, and I'm sure at many sites the HTML is owned and maintained by the developers once it's been handed off and marked up. In many internally-facing sites, simplicity and maintenance of the HTML probably takes precedence (in theory) over the site's look and feel.

Previous: introduction

Home

Next: template tasks