Posted by aaron at 06:02PM, Thursday, December 01st, 2005
Templating Languages and Windmills
I recently read a decent little article on templating languages by the guy who wrote Rails, and it helped me to articulate some of the things that have always bugged me about Java templating languages (Turbine, WebMacro, Velocity, and pretty much any system involving extensive use of Taglibs).
The way that most people have tried to sell me on templating is that it enforces a strict separation of content, presentation, and logic. They claim that, if you disallow scriptlets (raw code fragments, e.g. of Java, in your server pages), you can ensure that the pages are always presentation-only. But that's a bogus argument. [Many of these are the same people who don't know that, in a strict MVC model, you can use JSPs as both the view and the controller; they're quick to snap "but controllers have to be servlets," and seem baffled if I point out that JSPs *are* servlets. This has happened in at least two job interviews I can recall.] Sure, taglibs can wrap logic -- control structures like loops and conditionals and switch statements -- in neat tags that look like xhtml. But that's not removing the logic from the server page, or even abstracting its functionality to a higher level. It's just dressing it up in new clothes, in the fashion of the moment, pseudo-xml. The logic's still there, regardless of whether it's in an if statement in a Java scriptlet, or a <dsp:switch> tag in ATG.
The next argument I hear, usually right after the one above, is that templating is great because it allows split teams, composed of graphic designers or HTML/CSS whizzes on the one hand, and programmers on the other, to work with server pages simultaneously. My experiences with web development have never included a workflow like this. Without exception, the workflow everywhere I've worked has been: a designer delivers a mockup page in flat HTML, with images, and the programmers turn it into a dynamic server page. I understand that there are probably teams out there that work in the concurrent model, but, not ever having seen such a team (and also, I should note, only one industry friend that I've talked to has mentioned working with such a team), I tend to believe that this is an artificial division of labor, created by software architects who'd never actually worked in the real world, or, to be generous, who used a workflow that wasn't the norm. I'm also at a loss to explain how a designer who's perplexed by a simple if statement in a scriptlet, to the point that he can't edit a page with one in it, is suddenly going to be able to comprehend that if statement once it's wrapped up in pseudo-XML. Again, the logic's still there, it's just wearing different clothes.
The flip side of the above is that, for programmers, I think that logic embedded in tags is actually quite a bit harder to read and understand. The control structures embedded in XML tags are going to be a redundant syntax for the logic they're expressing. In this sense, templating is an abstraction, and by using it, you're placing an added burden of translation (from whatever templating tags you're using to the Java they abstract) on the developers reading and maintaining your page. If you're using a Java-based templating language, you can assume that any developer working on the page will know the syntax of a Java for loop. You cannot assume that any Java developer will know syntax for a loop in Struts, versus ATG, versus a proprietary in-house taglib. With experience, reading the syntax of whatever templating system you choose gets easier, of course. Still, the various templating systems don't share syntax -- so woe to anyone who switches from one to another. At a basic level, XML is going to be more verbose than almost any other programming language. Further, when you embed control structures in it, you're forcing a markup language to take on a role it wasn't really designed for. Why not use a tool more suitable for the job at hand?
One explanation that people offer is that, with tag-based templating, you can embed the logic in the pages and yet still have XML-compliant server pages. This is a bogus explanation. First, because you can easily embed scriptlets in comments, which will be ignored by any XML validator. And second, and more importantly, because using taglibs is absolutely no guarantee that you'll end up with server pages that are well-formed. Consider the following excerpt in ATG's JHTML:
<dsp:param name="array" value="Profile.prefGenres"/>
<%-- this tag contains any output to render before handling the first item that's being looped over --%>
<%-- this tag contains any output to render after handling the last item that's being looped over --%>
This example is perfectly valid in a JSP page running in ATG, but, because of those <ul> and </ul> elements, it's not well-formed XML.
Because of all these problems, and because XML is verbose, and because wrapping logic in XML elements blurs the distinction between what's content and what's logic, when reading the page, I don't think it's a good idea to embed simple page logic in templating tags.
One good reason to use taglibs is as a convenience wrapper for complex logic. If you're hiding a whole lot of processing and special-condition logic, which you need to run a bunch of times, behind a tag, and you can pass it a couple of parameters to it, that's great. I am fully in favor of using tags like that. (Or using scripting language function calls like that, for that matter.) However, I think it's a big leap from there to saying that you can or should use tags for everything, and scriptlets for nothing.
Overall, I feel like there's a lot of sloppy thinking that people use to conceive and defend templating systems. There are a few false dichotomies that get set up -- presentation logic versus controller logic, and page developers versus page designers -- but the systems that result don't enforce the former rigidly (after all, I can still make a page that redirects based on values, using only tags, in JSP, and I can still make a Java class (a Servlet) that generates content; what was that about separation of logic and presentation again?), and the latter doesn't seem to be based on usability testing or real-world problems so much as some guy smoking dope and thinking "wouldn't it be cool if I made a language that was kind of like XML?"
The thing is, languages have grammars. "Kind of like XML some of the time, with certain tags," isn't the same as "valid, well-formed XML, all of the time." "Helps to enforce separation of the view from the controller" isn't the same as "enforces strict separation," especially when a lot of the templating enthusiasts seem frighteningly inept at explaining the whole MVC concept. "Disguises logic as tags" isn't the same thing as "simplifies page development." If you want to create an XML schema and use that as a standard language to develop server pages in, and hook it up to whatever parser you like, that's great. If you're just going to cobble together a hare-brained concoction that takes bits from XML, bits from Java, bits from MVC, and bits from the W3C playbook, but doesn't offer a clear vision, or a well-defined grammar; which doesn't abstract logic, so much as make it look different; which doesn't build on the skills your developers have (reading, parsing, and writing Java), then I simply don't see the point.
All content copyright © 2001-2009 the owners of http://www.circa75.com/