On Tue, 18 Mar 2003, Chris Leishman wrote: > On Tuesday, March 18, 2003, at 10:59 AM, Matt Sergeant wrote: > <snip> > > Well, XSP is dynamic. So in order to know when the output changes > > you'd have to be able to follow the path of the code before it is > > executed. Which is basically the halting problem. > > Ahh - I see our confusion. I agree that you can't cache the output of > XSP because it is dynamic, but Tod's original statement was that having > an XSP page generated later in the pipeline results in the page having > to be recompiled to a perl module every time. However, as long as the > source XSP comes from a reproducible source (eg. XSLT transform) then > it should be theoretically possible to cache the compiled module.
Right. At the moment the AxKit cache is all-or-nothing. You turn it off and it's off for the whole request. We don't cache in the middle. Getting that right so that it doesn't cause too many cache checks in pipeline is tough. I'm not entirely sure how to handle it. One idea that sprang out of the AxKitB2B project was the user configures the cache to happen wherever he/she wants it to. This worked well, but you lose something because you now have even *more* to configure, and there's probably too much to configure in AxKit already! Still, it will probably all happen - it just needs tuits. > Interestingly, this would suggest to me that it would be much more > inefficient to have XSP earlier in the pipeline - since nothing after > it can be cached. The XSLT stylesheets can be cached (in memory, pre parsed). > <snip> > > On your namespace thing, I suspect this can be alleviated with some > > changes to your XSLT to suppress or properly output XML namespaces, > > but I don't have my XSLT books to hand to figure this one out. Perhaps > > some XSLT gurus here on the list can help. > > Ok. I entirely agree that my XSLT page is broken and should be fixed. > I think the XSLT processor is probably doing the right thing by > resetting the xmlns (although having it reset to empty is annoying - > but I don't think there's an alternative). > > However there is definitely still a bug if the XSP processor crashes > when there is an empty xmlns element. Eg. this .xsp page dies for me: > > <xsp:page language="Perl" > xmlns:xsp="http://www.apache.org/1999/XSP/Core";> > <blah xmlns=""/> > </xsp:page> Ah, thanks for that. Bug now fixed in CVS. -- <!-- Matt --> <:->get a SMart net</:-> Spam trap - do not mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
