afongen
Sam Buchanan's weblog.

Why JSP Sucks So Hard

Marc Hedlund writes about Why JSP Sucks So Hard. In a nutshell, separating Java code from HTML is on the right track but incomplete: you're still left with a bunch of stuff that makes sense neither to HTML jockies or their standard tools.

I've been thinking this with my early forays into Smarty. I certainly prefer working with Smarty to mixing up all my PHP code with the markup, but it's still way too easy to build business logic into the template, something that I'm trying to avoid by using a template system in the first place. Not just on general principle, but because of the confusion faced by the designer or whoever's now dealing with this little mini-language.

Microsoft's made some steps forward with ASP.NET, in which the template is a valid XML file (reminiscent of taglibs, if my incomplete understanding of both technologies serves me right), but the non-HTML <asp:...> tags in the are still going to throw off standard tools. Conveniently, Microsoft's got plenty of tools to use.

Zope's Template Attribute Language uses attributes instead of tags, but it is still a language, embedding logic into the template. Maybe I'm being too purist about that, but that really is the point of the rant, so bear with me.

Marc suggests something akin to what was done with CSS:

Give me a "code" attribute that I can add to any HTML tag, and overload the "id" attribute. Have the value of the code attribute be an opaque string referring to a codesheet, linked to the HTML document by a a '<link type="text/ccs" rel="codesheet" href="code.ccs">' tag. Have the codesheet use a CSS-style rules specification for indicating which Java (or whatever) class should consume tags with that code or id attribute. Then tell the HTMLer to add the "code" and "id" attributes to the right place in their existing documents, and they're done.

I think he's on to something. We'd need to work around some namespace issues (the code attribute has a specific purpose and place; this ain't it.), but things like TAL have already pointed the way. What I really like about his idea is that, as he points out, it doesn't bind the HTML language to any particular programming language. This would be a huge boon to development, especially if you use something like Perl or PHP for quick prototyping but have to use Java in production to assuage someone's concerns about stability or speed. :-) Just switch out the code in the back end.