‹ another wonderful example… •
No offence to Rick, but I’m looking at the facelets examples in his article and thinking, this stuff just isn’t attractive. I’ve been involved in some reasonably complicated facelet+JSF pages recently — there is nothing elegant about the combination of html, JSF components and facelet tags, nor the amount of background effort required to get things working nicely. Still it’s better than the alternative — being solely stuck with JSF.
Which got me thinking. I understand the goals driving JSF; even agree with the reasoning behind (some of) them. Some portions of JSF are useful… but the templating side of things is generally hideous. Leaving me wondering why they couldn’t do considerably better? (Well I know one possible reason — Design By Committee).
JSF apologists will now be saying, “but you get a lot for free with JSF that you’d otherwise have to code”, to which I (inevitably) reply, “yes, but the free stuff doesn’t excuse the amount of crud one has to deal with.” There’s no really good reason why the useful bits (-some- of the lifecycle stuff, the automatic binding and so on) have to be bundled into an all-encompassing framework. Personally, I’d be happier with a cleaner templating system, and some libraries I can use (or not) tied together with a vanilla old-school servlet. And anyone who thinks they’re really getting added-value with faces’ navigations rules configuration need to hit themselves with a clue-stick.
One thing I’ve decided I do like from the templating side of JSF+facelets, is xhtml-based templates — something I never thought I’d be admitting. Velocity or Cheetah have traditionally been my templating engines of choice, mainly because I prefer a clean delineation between code and (x)html. Standard JSF+facelets doesn’t give -any- clean delineation, so you might be wondering why I’m contradicting myself — however I’ve grown to like the idea of xhtml which validates cleanly while still in template form, but I’m advocating going even further. Get rid of the additional tags altogether. Even more extreme than Tag Attribute Languages (ala Zope), something like HTMLTemplate would be a start, but even then that’s almost too much markup. You can’t get any more separation between view and model than if there’s no code in your view at all.
For example, it only took a couple of hours to knock up a basic python templating engine that would inject this:
<html>
<body>
<div id="banner">
<p id="banner-heading">This is the banner heading which
will be internationalised.</p>
</div>
<div id="nav">
navigation goes here from an import
</div>
<div id="main">
<div id="content">
<table border="1">
<tr id="datarow">
<td id="datarow:elem:col1">the col1 property of an injected datarow object
will replace this </td>
<td id="datarow:elem:col2">col2 will go here</td>
<td id="datarow:elem:col3">col3 here</td>
<td id="datarow:elem:col4">col5 here</td>
</tr>
</table>
<select>
<option id="sel" value=""></option>
</select>
</div>
</div>
</body>
</html>
with dynamic values, using the element IDs to lookup a context and try to intelligently decide how the element content should be repeated, imported and so on. From my point of view, the nice thing is it has no (non-html) markup, other than an arbitrary naming convention for repeated elements. Code goes in the controller, where it should be.
Okay, I haven’t convinced myself the concepts are completely sound — this is a damn basic template, and as soon as you want to do something complicated the whole thing will probably collapse in a steaming heap of badly hacked goo. But I have proven a couple of ideas to myself, and the basic xhtml above looks a darn sight prettier than the equivalent JSF+facelets xhtml would be. With vanilla xhtml, there’s no reason why the design-by-gui crowd can’t still have their drag-and-drop, all-bells-and-whistles, create-the-page-by-wizard development environment, and those of us who find it 10-times quicker to work from a text editor can still do so, without having to look at the ugly excuse for templating we’re now stuck with as a defacto standard in the Java web world.
[Note: either 1) code to follow once I've decided this sort of templating actually works for more complicated cases... or 2) an embarrassed silence after I discover I've forgotten something really important and the whole idea flops miserably]
No comments yet.