On Monday, March 17, 2003, at 04:02 PM, Tod Harter wrote: <snip>
I think generally the best advice for using XSP is to use it first in the
pipeline and use XSP to build up all the data you will need later in the
pipeline, so you could simple have something like:
<header> <web:header name="HTTP_USER_AGENT"/> </header>
in your XSP and then in the XSLT you can match on that and do whatever you
need to do with it, like convert it to some HTML tags. In other words don't
try to add in DATA in later stages of pipelines. Think of your 1st stage in
the pipeline as producing all the data you will need, and later stages are
there to organize and present it.
Ok. Perhaps I'm missing something though - because this doesn't really fit with my stated goal. I have XML documents that represent the data I want to display as HTML to a browser (or as WAP, etc, etc). The XML document contains just the data - nothing about how it should be displayed (which I thought was kind of the point). This of course includes the fact that it contains none of the additional text/markup that is part of the HTML version.
However, to process first with XSP, the XML document would have to contain the required XSP tags to begin with - so it wouldn't be just the data anymore. Since it doesn't (and IMHO shouldn't) I have to use some sort of translation to convert the raw data into something that contains the XSP markup.
Eg. I start with:
<page> <para>Some text</para> </page>
Then, via XSLT, I turn this into something like:
<xsp:page>
<html><body>
<p>Some text<p>
<p class="footer">Maintained by <web:env_param name="SERVER_ADMIN"/></p>
</body></html>
</xsp:page>
This of course finally arrives at the desired output:
<html><body> <p>Some test</p> <p class="footer">Maintained by [EMAIL PROTECTED]</p> </body></html>
So how can I achieve this objective with the XSP first?
Putting XSP later in a pipeline is also horribly inefficient because the XSP
has to be compiled to perl for every single request. Normally a static XSP
page will be compiled to a perl module ONCE and the resulting perl script
cached, but if the XSP itself is dynamic then that cannot happen. You will
find that it can take a HUGE amount of excess processing when XSP is later in
the pipe. Even supposing you can get it to work reliably I do not thing it
will ever be a good idea to use XSP that way.
I don't know how AxKit tracks dependancies - but I would have thought it possible to derive that if the original .xml hadn't changed and the .xsl hadn't changed, then the output of that translation (the XSP page) hadn't changed and therefore it wouldn't need to be re-compiled. But perhaps I'm asking too much ;-)
Regards, Chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
