[mod_python] XSLT versus 'traditional' templating

On Aug 19, 2004, at 5:18 PM, Byron Ellacott wrote:

> My basic problem here is that there are trivial XSLT fragments that 
> may not be determinable until the entire source document has been 
> read. Consider <xsl:if test="/foo/bar">There is a bar 
> element</xsl:if>.  In this example, a source document may have no bar 
> elements at all, or it may have a bar element as the very last element 
> before closing the root foo element.  An XSLT processor cannot 
> distinguish these cases until the root element has been closed.

On the flip side, it can continue as soon as it sees a bar element. :)

>
> If the bar element appeared earlier in the document, a sufficiently 
> clever XSLT processor could continue processing as soon as that 
> element was encountered, but this falls down when you consider:
>
> <xsl:for-each select="/foo/bar">Another bar found</xsl:for-each>
>
> In this case, processing must be halted until the root element has 
> been closed, since another bar element may be encountered at any time. 
>  Once again, a clever processor could continue processing, storing 
> tree fragments for later use, but it could not output any further 
> elements until it was satisfied that the xsl:for-each had completed.

True

>
> So, I can see how a sufficiently clever XSLT processor could stream 
> output where possible, but this requires the stylesheet author to 
> carefully avoid any construct that would cause output to block.

This is true.  Usually though (and this was the case in my app), you 
spit out a bunch of header html without complex expression evaluation), 
so the user starts to see the top of your page.  That's all it takes to 
convice them that the app is fast, and if anything is slow, it's their 
browser.

In places where we were doing complex evaluations, we either moved 
around the xml input to accomodate, or move complexity into a hand 
coded SAX filter above the XSLT processor.

A good XSLT processor will stream whenever it can.  It is up to the 
architect/designer/programmer to allow it to.

> Most notably, any XPath expression used to control transformation that 
> cannot be sufficiently evaluated until the document is fully parsed 
> must be avoided, and for any non-trivial use of XSLT, this is, to say 
> the least, a hard task.

And it can usually be avoided very easily.

>
> If I'm missing something here, please fill me in, because I am in the 
> process of recommending an XML/XSLT approach to web development here 
> at work, and I'd love to strike out the cost to perceived response 
> times associated with a document transformation.

Make sure that XML is going to pay off first, and then XSLT can follow. 
  Don't let the cart lead the horse :)

Scott