Sorry for the delay!
Thanks for your answer, Peter.
I must admit that I did not compare the performance
between the aggregation and the transformer approach. The aggregation is just
one additional component in the pipeline, that has to process the big document.
Apart from that the necessary kind of processing of the big document
requires the XSL-transformer to build an entire DOMDocument before doing the
transformations, I guess.
So what I have done is I have written a Transformer
for handling expandable data like the directory tree in the Windows' Explorer.
It requires all input elements to have a unique id attribute. According to the
tree status stored in the session, the transformer will only forward the visible
tags and drop everything else. It also supports URL commands for setting
up the status tree (only root element is visible or all parent elements of
one particular one are visible), expanding and collapsing child elements.
Later transformers can then easily do the presentation of the visible part
of the tree and setup URL links e.g. for expanding leaf nodes
futhermore.
In most cases all SAX processing is done on-the-fly
without intermediate storage of all SAX element.
The quality of the code is probably not very high,
as I am not working with Cocoon for very long, but at least its documented. Do
you think this transformer could be useful for other people? And do you know to
whom I should give it?
Thank you and best regards,
Christian
----- Original Message -----
Sent: Monday, October 21, 2002 2:56
PM
Subject: RE: ServerPageAction:
XMLFragment reuse in XSL transformer
That
should work. I don't know if it is much (any?) more efficient
than using aggregation...
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
|