Bertrand Delacretaz wrote: ...
Advantages:
...
I agree with your motivation. I would also like to add that when we have introduced a separate formating layer and enforced side effect free templates, the conceptual difference between transforming XML input in a transformer and reading from, e.g. a rowset in a template generator, will be quite small. In both cases we have read only access to tree structured data.
Of course can we use different languages in generation and transformation if there are important conceptual differences, but I fail to see them and need more motivation and examples to understand why having the same language would be bad rather than an advantage. But I'm one of thoose people who regulary use XSLT as generator so I might not understand what is best for my own good anyway ;)
For those who has been concerned of that I'm (and others) are trying to introduce to much flexibility in templates (I'm not only talking with you Stefano ;) ), I would like to stress that I'm serious about forbiding side effects in templates. And this is a quite severe restriction in what you can do in templates. As far as I'm able to influence it, JXTG2 will _not_ contain the jx:set instruction. We can have an jx:let instruction for giving a local name for something, but no assignment. Before anyone got upset, we will of course have a JXTG1 back compability mode. But by taking away the side effects we can do some fairly radical optimizations in the pipeleine processing. It also enforces the "correct" SoC between view and control.
Disadvantages:
D1) The XYZTransformer is probably slower than a well-written XSLT transform. But it's also much faster than the XSLT transform that Bob tried to write. He's only been doing XSLT for four weeks and just plain hates it.
This is purely at the RT stage: But by writing our own transformer we can actually use some pull driven lazy evaluating methods in the transformer (this should trigger an alarm in Peter Hunsberger's mail filter ;) ), that allow for really radical optimizations.So we could actually end up with something that is much more efficient than conventional XSLT implementations. But it requires side effect free pipelines.
D2) The XYZTransformer is a memory hog on large documents, as it loads the document in memory so that the expression evaluator can process it easily (AFAIK the current XSLT processors do the same in many cases, however, so this might not really be a problem).
AFAIK current XSLT processors buffers input in all cases. With our own transformer we can do much better.
D3) Why so many steps? Generating XHTML directly could have saved some. But it doesn't help for RSS or WAP/WML, and the generation is actually much more complicated than what we see here, as configuration files and site menu definitions need to be aggregated in the page, with different variants depending on the final presentation target.
IMHO, the number of steps should depend on the result from ones analysis of what concern area that are involved in the problem area at hand, rather on some predefined idea about that an pipeline _always_ should consist of one generator, one transformer and one serializer.
<snip/>
XSLT is *the* stumbling block today,
Yes, many people hate it.
--oo--
BTW: I'm becoming more and more worried about the attribute template sytax that you used in your examples ;)
/Daniel
