Re: Adding XSP to an XSLT pipeline

[Chris Leishman]

On Tuesday, March 18, 2003, at 05:01 PM, Tod Harter wrote:
<snip>
Huh? I think you misapprehend the AxKit cacheing system....
Ok...let me explain my interpretation.  Let me define an example of 
XSLT->XSP:

	page.xml + page.xsl => page.xsp => page.xsp.compiled => page.html

Ideally, the process would be:

1) if (page.xml newer than page.xsp || page.xml newer than page.xsp)
        regenerate page.xsp
2) if (page.xsp newer than page.xsp.compiled)
        compile page.xsp
3) Output from compiled xsp is never up-to-date (it's dynamic) so rerun 
the xsp and generate page.html

4) page.html is the final result - send it to the client.

Of course, if AxKit isn't currently caching the intermediate 'page.xsp' 
then this doesn't work.  But in theory I can't see any reason this 
wouldn't work.

If XSP come first, it looks like this:

	page.xsp => page.xsp.compiled => page.xml + page.xsl => page.html

In this situation we have:

1) if (page.xsp newer than page.xsp.compiled)
        recompile page.xsp
2) Output from compiled xsp is never up-to-date (it's dynamic) so rerun 
the xsp and generate page.xml

3) if (page.xml newer than page.html || page.xsl newer than page.html)
	regenerate page.html     ** NOTE: this is always true since page.xml 
is always new

4) page.html is the final result - send it to the client.

So if nothing has changed, the XSLT->XSP case only needs to rerun the 
XSP.  In the XSP->XSLT case, we have to rerun the XSP _and_ reapply the 
transform.  Hence why I say it's less efficient.

Obviously this analysis only applies if caching is fully implemented.  
If only the first stage is cached, then the XSP->XSLT is more efficient 
as you claim.  But if it's an objective of AxKit to fully implement the 
caching (and perhaps I'll help out J�rg to complete it), then it's 
probably better not to bias people to the less efficient method.


Honestly, I don't think there is a really compelling reason to use XSP 
later
in pipelines. I've built so far several web apps with AxKit and the 
times I
was tempted to do so I quickly found that it was due to bad analysis 
of the
problem on my part. You might also really want to look closely at SAX 
filters
because they don't suffer some of these problems when used in later 
pipeline
stages, yet they offer many of the same capabilities as XSP (or XSLT 
for that
matter, they are rather in a middle ground there) and are also VERY
efficient. SAX can often process a page 2 or 3 times faster than XSLT.
I can think of a good reason.  If I want to make anything dynamic in 
the 'style' of the final output, then it would have to be in the 
original XSP document - which violates the idea of separating content 
from style.

If I wanted to add in, for example, a 'last modified' onto the bottom 
of every page - I'd have to make all my source documents look like:

<xsp:page>
  <content>blah</content>
  <last-modified><taglib:last-modified/></last-modified>
</xsp:page>
instead of just:

<source>
  <content>blah</content>
<source>
I'll have a look at the SAX stuff.

Regards,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]