On Mon, 2002-02-04 at 13:09, Melvyn Sopacua wrote:
> > Some of the exslt extensions will however cause that to
> > > > happen, probably defeating the way the current cache works.
> > > >
> > > > How do we deal with this problem ?
> > >
> > > AxNoCache On ?
>
> That's acceptible for this particular site. Not for some of the others
> we host or we need YA hardware upgrade.
> I suppose I'd have to reframe from putting banners in the same document as
> the content, which is exactly the opposite of the directions the advertiser
> market is taking.
This is fixable by having your final-step XSL use document() to suck in
the banner content (call it banner.xml).
The only problem is that AxKit is rather inflexible with caching and
with subrequests. If you could cache just the first few processing
steps, rather than an all-or-nothing deal, that would be very nice.
Also, if AxKit supports subrequest-called XSP pages, then that would
also be very nice. If you had both, then you could have:
(page).xml, which does a bit of work and generally isn't cached
(page).xsl, which just builds up the page and generall doesn't cache
root.xsl, which isn't cached, but uses document() to bring in:
menu.xml, which is XSP and is cached
leftnav.xml, which is XSP and is cached
shopcartnav.xml, which is XSP and is *not* cached
...for example.
I've been experimenting with building a page-building engine, and I
realized the caching is most naturally viewed as a "stylesheet engine",
just like XSP and XSLT. The "cache-save" engine would read a global
per-page flag to determine whether it should cache or not, and any step
before that engine could set that flag to set the policy.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
