cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <>
Subject Re: How Acceding request attribute in sitemap
Date Thu, 07 Dec 2006 13:00:31 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 :

  <type>Cocoon Users</type>

<xsl:template match="people">
    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

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

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.


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

View raw message