More on Logic in Templates

20 July 2007

My Logic in Templates post from a couple of weeks ago generated a couple of responses, and as expected the topic is very controversial.

In retrospect, one thing that isn't at all clear in my original post is that it wasn't so much intended as criticism of templating in Django, but more as some background on why Genshi supports Python expressions in templates. Some people have been asking me why on earth I'd think that'd be a good idea for a template language, so I wanted to put down my stance on the topic, and be able to refer to the blog post whenever the question comes up again. I guess it'll still not avoid endless debates, but at least I can just post a URL and lean back, while watching others fight things out—again.

In any case, I fully understand the rationales behind the design of the Django template language. In fact, if I had to sit down 3-4 years ago and design a template language, chances are the result would have been very similar, at least conceptually. And back when the Django project was first released to the public, I checked out its template language and thought it was pretty neat. To be honest, I'm a relatively recent convert to the “templates need to support non-trivial presentation logic” camp.

“Safe” Templates

But even though I personally prefer working with a template language that allows me to use a real programming language (Python, Ruby, etc), there is definitely room for template languages that put severe restrictions on what you can do with them. An obvious example is that you're running a site such as Typepad, and want to allow users to manage their own custom templates. As things currently stand, you wouldn't be able to do that using Genshi. You might be able to do it with Django templates, although I'm not sure whether it has good protection against things like infinite recursion in includes, and other things that could potentially wreak havoc but absolutely mustn't in shared hosting environments.

The focus of Genshi is different. It's really aimed at programmers who want to produce solid markup from their web-applications, without the awkwardness of building DOM structures in code. Ryan Tomayko described this very nicely in Web Services Infrastructure: Kid Templating. The approach works very well for any kind of HTML or XML output you'd want to generate from web-based applications, but it definitely isn't trying to compete with Django templates over the best way to let hosted users do their weblog templates with. At least not yet.

Programming vs. Design

Apart from security, the other major reason for not allowing the use of a true programming language inside templates is the separation of roles between “programmers” and “designers”. I have the strong feeling that this is a problem that desperately needed solutions five years ago, when HTML templates were literally packed with style information, and the specification of design aspects of web pages was sprinkled throughout templates in an extremely verbose and repetitive fashion.

But nowadays web design is done mostly in CSS. HTML Templates provide the document structure, in a way that's as semantic and clean as possible, while still providing the hooks necessary for styling via CSS. This is an area where the responsibilities of programmers and designers may overlap considerably, but in general I think that authoring templates is much less of a typical design activity than it was just a couple of years ago.

I get the feeling that some people debating the merits of different template engines haven't quite understood that change yet.