cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
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
like 

select="//book/section[@paragraph='here']/child::node()../../[count(child::node()=10)/@foo]"

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,

Ard

> 
> Simone
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message