Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 96214 invoked by uid 500); 21 Oct 2002 13:56:47 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 96192 invoked from network); 21 Oct 2002 13:56:38 -0000 Message-ID: <601F6322AD71D5118D6C0003472515290660D02D@sjmemexc1.stjude.org> From: "Hunsberger, Peter" To: "'cocoon-users@xml.apache.org'" Subject: RE: ServerPageAction: XMLFragment reuse in XSL transformer Date: Mon, 21 Oct 2002 08:56:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27909.962EC7F0" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C27909.962EC7F0 Content-Type: text/plain; charset="iso-8859-1" That should work. I don't know if it is much (any?) more efficient than using aggregation... -----Original Message----- From: Christian Kurz [mailto:crkurz@gmx.de] Sent: Saturday, October 19, 2002 4:53 AM To: cocoon-users@xml.apache.org Subject: Re: ServerPageAction: XMLFragment reuse in XSL transformer 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 ----- From: Hunsberger, Peter To: 'cocoon-users@xml.apache.org' 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:crkurz@gmx.de] Sent: Friday, October 18, 2002 1:42 AM To: cocoon-users@xml.apache.org 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 ----- From: Hunsberger, Peter To: 'cocoon-users@xml.apache.org' 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:crkurz@gmx.de] Sent: Thursday, October 17, 2002 11:26 AM To: cocoon-users@xml.apache.org 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 ------_=_NextPart_001_01C27909.962EC7F0 Content-Type: text/html; charset="iso-8859-1"
That should work.  I don't know if it is much (any?) more efficient than using aggregation...
-----Original Message-----
From: Christian Kurz [mailto:crkurz@gmx.de]
Sent: Saturday, October 19, 2002 4:53 AM
To: cocoon-users@xml.apache.org
Subject: Re: ServerPageAction: XMLFragment reuse in XSL transformer

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:crkurz@gmx.de]
Sent: Friday, October 18, 2002 1:42 AM
To: cocoon-users@xml.apache.org
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:crkurz@gmx.de]
Sent: Thursday, October 17, 2002 11:26 AM
To: cocoon-users@xml.apache.org
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
------_=_NextPart_001_01C27909.962EC7F0--