I'll try to implement a pipeline similar to
this:
FileGenerator ->
"MyFilterTransformer" -> other steps
The FileGenerator will read the big document and
is cacheable.
MyFilterTransformer will use the XMLFragment from
the session to forward only a small portion of the events from the generator,
following your idea. MyFilterTransformer is the first component in the pipeline,
which is NOT cacheable, as it returns different data on every
request.
To my understanding cocoon's caching strategy
should cache the pipeline as far as possible. In this particular case only
including the FileGenerator:
"The keys of all cacheable components are
chained, and together they build the cache key. The request is processed, and
the document is built. The cache stores the result of the _last_ component,
indicating cacheablility. The next time this document is requested, the key is
built, and the cached content is fetched from the cache.
Next, the cache asks all components of the event
pipeline, if their input has changed since the time the content was cached. For
example, the generator checks this by looking at the last modification date of
the xml document, the xslt transformer checks the date of the stylesheet,
and so on. Only if all state that the content is still valid it is used from the
cache. Otherwise, the document is generated from scratch. So the event pipeline
tries to cache as much of the XML processing pipeline as possible."
from New Riders, Cocoon: Building XML
Applications by Matthew Langham and Carsten Ziegeler, p. 182.
----- Original Message -----
Sent: Friday, October 18, 2002 4:23
PM
Subject: RE: ServerPageAction:
XMLFragment reuse in XSL transformer
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
|