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: [RT] the quest for the perfect template language
Date Tue, 08 Apr 2003 14:54:24 GMT
Stefano Mazzocchi wrote:

>on 4/6/03 11:48 AM danielf@lentus.se wrote:
>  
>
<snip/>

>>For XSLT-based generators and transformers however, uncontrolled use of
>>side effect is a really bad idea. First the specification doesn't say
>>anything about execution order, execution order might be implementation
>>as well as optimization level dependent. 
>>    
>>
>
>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.

<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
>(yet).
>
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>

>>As I said above I believe that using side effects in an uncontrolled way 
>>in pipelines creates problems. What I had in mind for the serializers 
>>was a very restricted form of side effect. Things like putting a dom tree 
>>  in a request parameter or FOM variable and write to a file or and 
>>XMLDB, maybe one could initialize java objects from xml an put them in a 
>>FOM variable. The main idea is to make it easy to package input data in 
>>such a form that it is easy to manipulate it in flowscripts. I think it 
>>would be a bad idea to write procedural programs in a serializer. My 
>>ideas about this is still quite vague.
>>    
>>
>
>I see.
>
>What would you think of something like
>
> process(uri,dict,dom)?
>
>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.

<snip/>

>> > third concern: use of XSLT for generation
>> > -----------------------------------------
>> >
>> >  1) it should allow the use of literal result elements stylesheets
>> >     [http://www.w3.org/TR/xslt#result-element-stylesheet] as templates
>> >     for a generator
>>
>>I took a look at the TraxTransformer, it should be easy to write a 
>>TraxGenerator, and if we use sources for embedding the OM one could 
>>remove more than half of the code as it handles parameters to XSLT, which 
>>we wouldn't need anymore.
>>    
>>
>
>right, but my problem with document() performance still remains, even
>compared to <xsl:param> or {$request} what do you think about that?
>
I'll, get back to that later.

>> > The three concerns are fully isolated and can be independently
>> > implemented/designed.
>>
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.

/Daniel Fagerstrom



Mime
View raw message