cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Date Mon, 06 Dec 2004 09:10:50 GMT
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


Mime
View raw message