cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] the quest for the perfect template language
Date Wed, 09 Apr 2003 20:19:25 GMT
on 4/8/03 4:54 PM Daniel Fagerstrom wrote:

> Stefano Mazzocchi wrote:

>>execution order of what? I can't follow you.
> Execution order of functions in xpaths e.g., say that you have the xpath 
> expression "my:foo() + my:bar()", then the processor could choose to 
> execute foo and bar in any order, depending e.g. on optimization 
> strategies As long as you don't have any side effects that's ok. An 
> other example: lets say that you have a variable definition as follows:
> <xsl:variable name="foo" select="my:foo()"/>,
> the the processor could choose to evaluate my:foo() during the 
> evaluations of the xsl:variable element, but one could also have an 
> implementation with lazy evaluation of variables, where my:foo() is 
> evaluated first when some other template is accessing the variable. Such 
> implementation works perfectly as long as you don't have side effects, 
> but would have quite unintuitive effects with side effects. There have 
> been some experiments with lazy evaluating implementations of functional 
> languages (e.g. LML, Lazy ML), and IIRC lazy evaluation could lead to 
> very good performance.
> Now, I don't know if it would be any gain to build an XSLT processor 
> with "exotic" evaluation order, but I would not like to base my code 
> investments on a non standardized execution order in XSLT processors. 
> Conclusion: avoid (unrestricted) side effects in XSLT.

I see.

> <snip/>
>>Might be, I really don't know nor have enough information to provide. I
>>never used a transformer with side effects, nor found the need for one
> Cocoon ships with a number of transformers with side effects: 
> SQLTransformer, WriteDOMSessionTransformer, SourceWritingTransformer, 
> SessionTransformer, and possibly others. In some of my webapps I have 
> chosen to use the SQLTransformer for saving XML-input data instead of 
> using actions. It works fairly well if you know what you are doing, but 
> there are some subtleties. Anyhow I hope to be able to use flowscripts 
> for such things in the future.


> <snip>Discussion about how to access object model data in XSLT, I'll 
> have to think a little bit more about that and return to the topic 
> later</snip>


>>What would you think of something like
>>so that you pass a dom/jdom object that gets populated by the pipeline
>>you call from the flowscript?
>>that way you could extract information (using jxpath, for example) then
>>discard it or serialize it later by yourself.
>>I'm quite in wild mode right now so take with with very foggy idea that
>>just popped up.
> I think that it is a good idea, the multi path idea I proposed is 
> probably FS anyhow. What you propose should be enough for the use cases 
> I have in mind. Maybe the dom object in the parameter list to process 
> could be replaced by a modifiable source so that you can choose from the 
> flowscript in what type of object you want to store your data. Dom might 
> not be the optimal storage place in all cases. Using the DOM interface 
> and adapting other data structures to DOM with e.g. Domify is another 
> option.

When I say DOM nowadays I really mean "one possible data model of an xml
document", where the data is really stored and who provides the real
implementations are separate concerns.

>>>>The three concerns are fully isolated and can be independently
> I implemented a basic TraxGenerator based on the TraxTransformer code, 
> it was quite straightforward as expected. I can submit a patch if any 
> one want to work on that part immeadetly, but I don't think it is very 
> useful before we have sorted out how to submit data to the XSLT 
> processor in an efficient way.

I agree, let's try to sort that out.

So, this list seems full of XSLT lovers, then get your brain cells
working: how do we sort the performance issues of document()?


View raw message