cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <>
Subject RE: How Acceding request attribute in sitemap
Date Thu, 07 Dec 2006 18:33:36 GMT

> Ard Schrijvers wrote:
> >> It's not made in single steps (generator generates all XML, 
> >> transformer
> >> 1 transforms it, transformer 2 transforms it, serializer 
> >> serializes it),
> >> but it a smooth flow of elements.
> >>     
> >
> > About the smooth flow of elements, I agree untill you hit 
> an xsl transformation (xalan/saxon) :-)
> >
> > Ard 
> >   
> Well, XSL needs to cache SAX events sometimes (and is not the only
> technology nor the only cocoon component).
> For example, if I have :
> <people>
>   <type>Cocoon Users</type>
>   <person>
>     ...
>   </person>
>   <person>
>    ...
>   </person>
> </people>
> <xsl:template match="people">
>   <p>
>     Hi, here is the list of <xsl:value-of select="type"/>, they are 
> <xsl:value-of select="count(person)"/>
>     <xsl:for-each select="person ........
> The xpath expression count(person) need to wait until 
> </people> arrives,
> only at that point it's possible to say how many "person" elements are
> there.
> So, what happens in the pipeline is that the generator sends events
> smoothly, xsl receives the people element, matches a 
> template, and sends
> smoothly the <p> element and the text "Hi, here is the list 
> of", and the
> serializer sends that to the browser. Then generator 
> generates the type
> element, xsl can now send the text "Cocoon Users, they are" to the
> serializer and to the browser.
> But now the XSL cannot send anything to the serializer until all the
> <person> elements are streamed by the generator, and </people> is
> encountered. This means that XSL processor will need to 
> buffer (save in
> ram) all the <person> elements, then count how many they are, and then
> reuse them to execute the following for-each.
> The matter is by far more complex than this : what if later in the XSL
> there is an expression like /people/person[1]/name or similar? AFAIK
> (but I'm not updated to recent improvements), XSL processors need to
> know all the xpath expressions they will have to resolve, buffer
> elements accordingly, calibrate sax events output based on 
> when they can
> send out having resolved the xpath expression when they 
> encounter them,
> and free the buffer ram only when no other expression will need that
> elements anymore (which is again veeeery difficult to understand,
> consider if there are conditional call-templates).
> A good rule is to always try to consider how much information the XSLT
> processor will need to buffer to resolve a single xpath expression,
> cause that means that it will be slow, not smooth (the 
> browser will have
> to wait until all <person> arrive just to display the number, the user
> will see the page is not smooth etc..), and more important it will
> consume RAM to buffer events.
> Back to the previous example, just moving the number AT THE END of the
> list instead that at the beginning can solve a lot : XSLT 
> processor can
> perform the for-each cycle and stream to the serializer as soon as the
> <person> elements arrive, so the user will see the page composing
> smoothly. Also, theoretically at least, it will not need to buffer the
> <person> elements, it can count them as they arrive, so will 
> not consume
> ram.
> On a static file this is not very important, but consider if the
> <person> elements are being generated by a DB query, and result in a
> thousand elements, and for each person a lot of data is given. In this
> worst scenario the XSL processor will have to use a lot of 
> ram to store
> the thousands elements (<person> plus all <person> 
> descendants), and the
> user will be sitting in front of the computer with the browser
> displaying nothing until all the DB processing ends, </people> is
> streamed, and finally that number can be calculated.

Better copy-paste work, haha. No, good explanation, though I would like to try and measure
this begin and end person count thing :-).

Anyway, rule of thumb: try to do everything you want in xsl with xsl:apply-templates, avoid
sorting, stay as far away as possible from previous next sibbling kind of things, or expressiions


They really make people wait, and if you do not understand instantly in an xsl how it works
while you wrote it yourself a week ago, you have done it too complex,


> Simone
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message