Several years ago there was a trend in Java web frameworks to use XML processing as a foundation for the framework logic: take the data from database and present it as XML document (either convert it from relational data, or use XML capable database), and transform it to HTML using XSLT. There were some books written about it, and some frameworks created (like Cocoon). After some time the hype started to decline, and currently virtually no modern web framework apply this approach, I think.
Actually I’ve never used it on myself, but I liked the idea at that time. It seemed to be clear and powerful. Funny that only now I have a chance to check how it works in practice. And at least now I know why this approach failed.
For two weeks, I’m outsourced to help some company in their web project. They use their own, home-made web framework for this, to talk to their own, home-made document-repository system. Unfortunately, both seemed to be buggy and unstable, though they say that’s not the first project they use them in (I can’t believe it’s true, really). I guess they would be better off using standard Java Content Repository (JSR-170) for implementing documents repository, and some modern web framework instead of their own home-grown one. If they insisted on XML/XSLT transformations, they could use Cocoon. At least there would be more documentation available, and it would be well-tested and stable. But ok, that’s not the first company that suffers from NIH syndrome, or guys are simply too lazy or overloaded to look around for other stuff. The interesting point is: how the XML-based processing works in practice? The short answer is: very poor. And the weakest link in the whole chain is XSLT.
XSLT bloat
I won’t dare to say that XSLT is worthless – perhaps in some contexts it can be useful, especially for transforming one document tree into another (valid) document tree, i.e. from DOM to DOM. XSLT gives you guarantee that input and output documents will be valid XML – this is crucial e.g. in SOA applications, transforming one document into other documents, to be processed by machines. (X)HTML is a document tree too, at least formally, but from the point of view of web browser to have perfectly valid XHTML is good, but not crucial, and from the point of view of web designer or developer the DOM behind it doesn’t matter at all, and making the template valid XML is of no importance. For dynamic generation of HTML pages in most cases it is much easier if you treat the HTML code as a unformatted text, and make a web page template by embedding some special processing directives in such text. This approach was applied by JSP (first with scriptlets, and than with JSTL), Velocity, FreeMarker, and other technologies. Neither of those technologies use the strict XML as template. On the opposite side we have JSPX (JSP using strict XML) – it never caught on and I guess many Java developers have never met it; and XSLT.
I’ve used a lot of JSPs with JSTL. It wasn’t perfect, but it worked. Now I have to do the same with XSLT and it’s a nightmare. Things that took me half an hour to do with JSP take several hours in XSLT. This is a list of things I hate the most in XSLT:
1. Conditional arguments. For example: how to hide the row in table (using different CSS style), based on some CONDITION, with XSLT?
2. Nested loops. In JSTL the <for-each> tag has the var attribute, which is the variable that gets assigned the current element from the collection during looping.
3. Every XML-like fragment which is not an actual XML must be escaped.
4. The functional approach applied in XSLT design, instead of the well known (for all programmers) procedural one, makes “thinking in XSLT” very hard.
5. No formal XML schema for XSLT 1.0 exists. At least I couldn’t find it – there is only unofficial DTD somewhere. This ruins IDE code completion abilities.
Thanks
By Grzegorz Borkowski