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.
maps 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 littered
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.
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 :)