The ever-interesting Jeff Atwood correctly points out that many frameworks force you to create tag soup – a horrible mess of executable code and HTML markup. Commenters suggest a number of solutions but none are really satisfying.
Our in-house framework started back in the bad old days with Java emitting HTML directly – surely the worst of all worlds. We figured out early on that it was better to create XML first, and transform with XSLT; for instance, this reduced the pain of generating reports from our screens, since we can transform the XML to flat files and PDFs.
However, even XSLT can be pretty soupy:
<xsl:choose>
<xsl:when test="@current">
<b><xsl:value-of select="@number"/></b>
</xsl:when>
<xsl:otherwise>
<span style="cursor: hand;">
<xsl:attribute name="onClick">
<xsl:text>go('</xsl:text>
<xsl:value-of select="@number"/>
<xsl:text>');</xsl:text>
</xsl:attribute>
<u><xsl:value-of select="@number"/></u>
</span>
</xsl:otherwise>
</xsl:choose>
This implements page numbers with links to all but the current page, similar to Google’s Goooooooooogle:
1 2 3 4
Not only do we have lots of XSLT logic with smatterings of HTML thrown in, we even have some inline JavaScript at lines 8-10, which is code inside markup inside code!
We could clean up this particular example but it’s way too easy to create a mess like this. So we’ve gradually introduced more and more generic templates that take XML of a certain form and produce the corresponding HTML – including all the messy bits like JavaScript. For instance, here’s how we render a table of data with headings, column selection, and sorting:
<xsl:call-template name="chunk-multiple">
<xsl:with-param name="node" select="data/content/section/dataset[@name='TABLE']"/>
</xsl:call-template>
Yes, it’s cheating because the template code is still tasty tag gumbo. But we have only a few templates, and we can concentrate on making them as readable as possible with comments and careful layout, while each individual application screen is defined in just one language – XSLT.
There’s a lot more cleaning up we could do with templates for our buttons and forms, but at least it’s more broth than chowder. Bon appétit!
As for the Javascript bit you could go unobtrusive
http://labs.adobe.com/technologies/spry/articles/best_practices/separating_behavior.html
Hmm, I find that a bit harder to follow, because there is no clear link between the element affected and the JavaScript – I have to go read an external file to see that they are linked. Also, we have some impatient users who don’t wait for the page to fully load before they start clicking – doesn’t seem that this method handles this, does it?
My XSL is a little rusty, but if memory serves this:
<span style="cursor: hand;">
<xsl:attribute name="onClick">
<xsl:text>go('</xsl:text>
<xsl:value-of select="@number"/>
<xsl:text>');</xsl:text>
</xsl:attribute>
<u><xsl:value-of select="@number"/></u>
</span>
could be re-written as:
<span style="cursor: hand;" onclick="go('{@number}');">
<u><xsl:value-of select="@number"/></u>
</span>
Which would mean less tag gumbo in those templates…
Thanks Steve! That seems sensible though I haven’t tried it – this code is pretty ancient, so the funny syntax is probably working around some funny bug or other. Of course even your shorter version still has JavaScript inside HTML inside XSLT!