On Tuesday 01 February 2005 08:55 pm, Dave Roe wrote: > What would be the best approach to handle an XSP page that included > <taglib1:something />, outputting <taglib2:somethingelse />, expecting > that the output is to be re-run through the XSP processor and onwards? > > Essentially, XSP -> XSP -> XSL -> XSL -> output > > I've read a lot about keeping your XSP at the top of the pipeline, and > the caching reasons for that. What would be the case with having two > XSPs at the top of the pipeline?
It really doesn't matter WHERE in the pipeline after the first step XSP is, the caching issue is that if the input to XSP changes, then it is going to force a recompile of the generated perl code, which is SLOW. When your XSP is at the start of the pipeline, then its (most often) the same every time and so it only gets compiled on the 1st page hit to your site, but (in your example) XSP #2 is based on the output of XSP #1, which being dynamic means EVERY page hit results in regeneration of perl code and then recompilation of that code. This would be true regardless of what kind of processor comes first in the pipeline, XSP isn't first, thus it is processing dynamic input, and its not really much good for that... The alternatives have been pretty well discussed as well. In your example you could redesign your pipeline as follows: XSP -> XSL -> XSL -> XSL -> output and have XSL #1 merge in content that you now produce in XSP #2 via the 'document()' function. Or you can use XInclude within XSP #1, or other taglib based including functions. Or you could accomplish what you want perhaps by writing a custom provider module. To be honest I think most people using AxKit have come to the conclusion that XSP (and other similar language > > /dave > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Application Development and IT Consultant --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
