> > 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/[EMAIL PROTECTED]'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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
