Forum OpenACS Q&A: Response to Utility of XSLT?
simple yet useful templating model. Just simple row structured data sources, and
a couple of conditionals and and iterator in the templating language seemed sufficient for almost everything. More complex pages could be formatted as straight procedural code.
The first ACS 4 Java release had a straight port of the ACS 4 Tcl template system, which I think worked quite nicely.
In fact, it seemed like it would be easy to extend that template system to handle XML, in a lot of cases, by converting the XML to a data source. I wrote a simple XML DataSource class, which could take a
block of XML and convert it into a data source. I have a pointer to
an older writeup of this at http://domokun.wem.sfc.keio.ac.jp/xmldemo/
I actually improved it some more after that writeup, adding in a hook to the XPATH parser, so you could define a data source that would specify an arbitrary XPATH expression to grab any chunk of XML out of a raw XML source.
The advantage was again that this handled almost every common case of
wanting to use XML data, and you never had to touch a DOM tree by hand. For the more complex cases, you can always manually pick apart the XML if you need to. But the common case was to treat data as
basically row structured, or to coerce it to that with some easy to use tools.
XSLT is interesting because it is so many different things, but also
that is part of it's problem. It is really best as a tree-reordering language. It is a very compact way to transform one XML tree into another. But it is a crappy procedural language. And it is a verbose and clumsy templating language. But still, some people believe that the benefit using a single language will have ultimate cost savings somehow, in user training or system maintenance. I am not convinced from what I have seen so far though.
Anyway, beyond just the XSLT and templating question, I think it's kind of strange watching how ArsDigita threw out almost everything they had working and started over. The new application model they are using, of persistent user interface objects and Model-View-Controller, etc, was tried by a number of other web application framework products over the years, such as the original NeXT NetObjects product (admittedly, that was in Objective C). I think
in many cases those systems proved to be difficult to
customize and maintain, because of the extra layers of abstraction above the database and the extra layer of abstraction between the application and the HTML pages.
I also think the bboard example is something to be wary of, because, perhaps not coincidentally ,the bboard functionality of successive releases of the ArsDigita tools has been getting steadily less
functional and efficient.
The argument that it's easier to reformat the bboard in lots of different ways is again ignoring the efficiency issue. I would worry that on top of an inefficient underlying representation, adding the overhead of XSLT processing is probably going to hurt the performance (although the
XSL template processor supposedly compiles the templates, still I don't know how efficient the whole thing is compared to straight procedural Java as compiled by the original ACS4 templating system).
Looking at the ACS 5 stuff reminds me of something Greg Haverkamp used to say, "Too many moving parts..."
