Well,
obviously, it something changes on every request then, by definition, it isn't
cacheable. However, I believe, with aggregation, only the components that
are marked as invalidated in the cache are rebuilt on a new request; the rest of
the data stays in it's respective cache. This does mean that the
aggregated document is rebuilt each time (I have no idea what the impact of that
would be). But the "large" document source would stay not be retrieved
from scratch.
Perhaps using the document function as Olivier would avoid this. At
one point document did not check cache validity at all and you would only
get a newer version of the data if the main data was invalidated in cache. I
think this has been fixed in 2.0.3. The problem is how to get the URI
resolve for the document function to fund the data in session. Someone
else will have to tell you how to do that (and if it's even
possible)...
-----Original
Message----- From: Christian Kurz
[mailto:[EMAIL PROTECTED]] Sent: Friday, October 18, 2002 1:42
AM To: [EMAIL PROTECTED] Subject: Re:
ServerPageAction: XMLFragment reuse in XSL transformer
Thank you very much for the quick feed-back!
The idea sounds great and is a lot cleaner,
than fiddling something in some XSL extension.
I am not sure about the cachaebility: the
XMLFragment specifying, which nodes to filter from the big input document,
changes everytime, so Cocoon would need to parse the source file on every
request (, if my understanding is right).
If I'd slidely change your approach to
implementing the same approach into a transformer component. This transformer
component will not be cacheable, but at least the generator in front of it
would be.
Thanks again,
Christian
BTW, thanks also for the code snippet. It helps a
lot, as soon as it comes to thinks like the ObjectModel, I start feeling
uncomfortable.
----- Original Message -----
Sent: Thursday, October 17, 2002 6:46
PM
Subject: RE: ServerPageAction:
XMLFragment reuse in XSL transformer
There's probably about half a dozen ways to do this. Perhaps
one of the simplest is just to create your own caching generator and use
aggregation (with any other XML you may need) in the
pipeline.
In
the generator you'll need to implement the setup method to see the
objectModel, something like the following:
private gunk mySessionData = null;
public void setup( SourceResolver resolver, Map objectModel, String
src, Parameters parms ) throws
ProcessingException, SAXException,
IOException {
if (mySessionData == null )
{
super.setup(
resolver, objectModel, src, parms );
Request
request =
(Request)ObjectModelHelper.getRequest(objectModel);
Session session =
request.getSession(false);
if (session != null) {
//
save a pointer to your session data for use in the generate
method
mySessionData = ....
}
} }
Now in your generate method just pick up whatever data hangs off of
"mySessionData" and away you go
-----Original Message----- From:
Christian Kurz [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 17,
2002 11:26 AM To: [EMAIL PROTECTED] Subject:
ServerPageAction: XMLFragment reuse in XSL transformer
Hello cocoon-users,
I need to generate some tiny XML elements
(XMLFragment) within a ServerPageAction and I would like to use this
XMLFragment later on in an XSL transformer, that is fed by an xml
generator. The XMLFragment captured in the
ServerPageAction is basically saying, which nodes are to be returned from
the big input document.
From some other message in this group I have
understood, that passing objects is only possible through session or
request objects, but not through sitemap variables. I don't like to use a
request generator as the starting point of the pipeline, as I'd loose
cacheability at a very early step in the pipeline. With a quite
big xml input document, this does not seem a good idea to
me.
So I am currently struggling how to get a
piece of XML, that is attached to a session or request object, into
the xsl transformer. Has anybody tried this before e.g. using an XSL
extension?
Any help or hints appreciated!
Thank you in advance,
Christian
|