We have a couple of pages at our site using a pipeline like this:
xsp -> xslt -> xsp -> xslt
We know this is inefficient, but we chose it rather than sacrificing simplicity in some of the involved taglibs.
We had to change the
if (exists($cache->{$key})
&& !$xml->has_changed($cache->{$key}{mtime})
&& defined &{"${package}::xml_generator"})in Apache::AxKit::Language::XSP::handler() to
if (exists($cache->{$key})
&& !$xml->has_changed($cache->{$key}{mtime})
&& defined &{"${package}::xml_generator"}
&& !$package->has_changed($cache->{$key}{mtime})Furthermore we changed Apache::AxKit::Language::XSP::Page::has_changed() to return 0 by default.
Any .xsp page wishing to use multiple xsp passes now has to define its own
<xsp:logic>
sub has_changed {
my ($package, $mtime) = @_;
return 1;
}
</xsp:logic>to bypass the cache.
The particular .xsp pages in question at our site aren't heavily used so for now we live with the performance hit (which we haven't felt much though).
Kind regards,
Jan Bauer Nielsen Center of Knowledge Technology, Technical Knowledge Center of Denmark Anker Engelunds Vej 1, Postboks 777, 2800 Kongens Lyngby, Denmark Direct: (+45) 4525 7221, [EMAIL PROTECTED]
Matt Sergeant wrote:
On 2 Feb 2005, at 16:55, Dave Roe wrote:
In my mind, it is not a matter of whether the Perl code behind the taglib needs to be re-compiled, as it's not changing. It is more a matter of how to structure the pipeline so that the XML can undergo multiple XML transforms via taglibs.
The problem is that the no-caching of XSP is slightly hard coded. There are some features in there for specifying has_changed(), but nobody has yet used them to any effect (if you succeed then let us know!).
So even if you could pass the output to XSP again, the internals of axkit would try and run the first XSP every time, causing you really bad slowdown.
There may also be a problem with the namespace XSP gets compiled into - I think I bound it to just the filename (assuming that there would be just one XSP run per file) rather than to the filename and the position in the pipeline...
If it sounds like you're going to need to go digging into the internals it's because you are :-)
Matt.
--------------------------------------------------------------------- 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]
