Templates: Good or Evil?
This cry and whine that draconian handling will break your page and make your users suffer for you if you have a single error is just another legacy of HTML we’ve gotten used to: our toolchains tend to be of the “glue strings together” (aka templates) variety. ... There should never be any part of your publishing toolchain just gluing strings together. Ever.
Source: Aristotle Pagaltzis in a comment on "The Future: HTML or XHTML"
There’s no rule that says templates must only be used to generate HTML. Indeed, many of the RSS and Atom feeds in the wild are generated from some form of template. They are never automatically-generated-behind-the-scenes using language bindings and are very rarely generated using some kind of DOM/SAX API.
Source: Web Services Infrastructure: Kid Templating
I've been meaning to write about this for some time now, though I've never had my thoughts together to any degree to mount a decent case for either side. Problem is, I haven't gotten much closer now, but I figured I'd at least post a few thoughts and conjure up a vague sketch of the issue.
You see, I think it all goes back to thoughts about which I posted almost three years ago. On the one hand, producing something like XML using "proper" DOM invocations and handwavings seems like the "correct" thing to do. Yet, on the other hand, using a templating system lets me get down to business much more quickly and with much more clarity and succinct code.
Yeah, templates provide a range of flexibility sufficient to aim the barrel at your own toes, while an API like the XML DOM keeps everything on the rails--but sometimes you know where you're going and don't need the rails to get you there. Furthermore, isn't it possible to make a template system that Does The Right Thing?
Anyway, it's rather apparent that I'm solidly in favor of templates: After all, a book of mine just hit the shelves which is just rife with template-based generation of RSS and Atom feeds.
My only issue, really, is that I feel vaguely guilty about it.
Archived Comments
Aristotle: Now here's where I think certain templating technologies get interesting, and may Do the Right Thing. My so-far-favorite templating kit, ZPT, wants well-formed XML as templates--although I think that restriction is unfortunately relaxed as a nod to HTML. On the other hand, my possibly-new-favorite templating kit, Kid, demands well-formed XML as templates. In case you haven't played with them, these two template languages center around the idea that certain attributes on elements define where content provided in a data structure should be inserted / swapped in by the template engine. The engine handles character encodings and such to ensure that the well-formed template results in a well-formed document. Does this match up with what you say up there?
map
s into the code for output loops. I have to note though that I used it as a sort of template language in its own right – I never litteredprint
s all over my code, I kept all the calls in a single place, in fact, usually a single expression. That is also why I find it strange that people create template languages for PHP, which was itself born as a template language. What matters is that the output generation is separate from the processing logic, whether or not the template and the code are in different languages. Anyway, I digress. What I wanted to say is, no, I hadn’t seen either ZPT or Kid. I had put off reading the lesscode.org article you quoted and went back to it after responding here. Now that I’ve read it, I admit I’m intrigued. I’ll have to look into Kid; it sounds like an interesting take.Ah hah, yeah, that's what I was fumbling toward with the sleepy tail-end of my comment. Logic and presentation in separate blocks / files / etc. And then, my take is that if you're going to have your presentation/view separate from the logic/controller, you may as well code the presentation in a form as close to the goal as possible (ie. in XML or HTML, not in s-expressions or the logic implementation idiom)—especially since oftimes you've got separate people or teams working primarily on each. I suspect, however, that a templating system like Kid goes quite a ways toward solving the problem of "gluing strings together". I almost wish it had been further along / I'd been more aware of it before I'd reinvented my own wheels for my book using Python string templates and funky map classes.
That's the idea. The correctness of DOM/SAX based contruction with the ease-of-use of templating. The future of Kid is somewhat uncertain. I'm hoping to wrap up 1.0 and stabalize it for Kevin and TurboGears but what I'd personally really love to see is the general concept of "structured templating" reach a wider audience.
Oh, I don’t disagree at all. I have been annoyed at the state of XML generation at large, myself. Kid looks very nice, except I have no use for it, being that I’m still a Perlista. (Python just doesn’t feel right to me – like wearing a badly fitting tuxedo.) I’m wondering how much work it would be to port it or a close copy to Perl…
Heh, yeah. Your MT installation permitted Markdown but no literal tags, which caught me off guard once or twice until I noticed. But thankfully it had a preview button, so I could figure it out. I hate how WordPress does not ship with preview button available and enabled by default, and the default configuration doesn't even mention the expected formatting anywhere either. I just suspected that your WordPress was vanilla and used HTML on that hunch – and it worked. Phew. Maybe you can install the gagdget that Ryan uses on lesscode.org? I love that.
Your wish is my command. At least, in this instance. I pawed through Ryan's HTML source and got sufficient clues to install this thing and shamelessly steal a snippet or two. Let's see if this preview works and if it accurately reflects what this will look like when I post...
I maintain Oddmuse, a wiki engine written in Perl, using CGI.pm to generate the HTML. Often people want me to switch to templates. At the moment, when you want to radically change the HTML for the stuff that is not the wiki content, ie. headers and footers, you need to override the Perl subs that I provide. Somehow that strikes me as natural and easy, but many of my users seem to disagree, preferring to learn a templating system instead of learning to write Perl code. I'm still undecided about the issue. At the moment I'm still sticking to the "write Perl code instead of templating" because being able to write Perl code will make so many other task easy.
Alex: Well, from my perspective, I've worked on a lot of teams where you've essentially got two roles—software engineer (SE) and interface engineer (IE). Depending on the company and the team, the SE might understand Perl/Python/Java/SQL while the IE might understand HTML/CSS/Javascript/Flash. There's usually overlap, of course, but these are the roles on paper at least.
When you're trying to come up with an overarching framework which accomodates collaboration between these two sorts of people and their respective skill sets, it helps to have a bridge between the logic and the presentation which can keep the Perl out of the HTML and the HTML out of the Perl.
On the other hand... A project like Oddmuse likely has an entirely different user and developer base than the projects I work on at my day job :)