I am carrying this over to dev@ so other developers can comment.
Leszek Gawron wrote:
Unico Hommes wrote:
Unico Hommes wrote:
Antonio Gallardo wrote:
Upayavira dijo:
Antonio Gallardo wrote:
Upayavira dijo:
Alan wrote:
I'm wondering if there is a way to cache JXTemplate, or any ordinarily uncachable pipeline, maybe from flowscript, by teling Cocoon that for this URL this pipeline will not change.
I have a JXTemplate that generates some XML based on request parameters, and for a given query string, it will always produce the same XML output.
Thank You.
JXTemplateGenerator in CVS is cachable now.
See:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108607750303449&w=2 for
the original 'spec' that is what I believe has been implemented.
Hi:
In the CVS the JXTG includes a patch that cache the compiled JXTG source.
That way a second run is only interpreted. Before the patch JXTG compiled
and then interpreted the JXT source file.
Is this what you are expecting?
This is not what I was suggesting. The patch that I understand has been
made allows the caching system to decide whether or not to cache the
page. Hence, generation is avoided completely if necessary (of course
the page needs to be interpreted to identify the caching details, but
much less work is required than if full generation takes place.
I am not sure if this was coded after the discussion. Can you provided info about the status of that?
Surely you couldn't have missed it. You committed it:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/generation/JXTemplateGenerator.java?r1=1.46&r2=1.47
Now reviewing the patch, I can't imagine how this is going to work. Both cache key and validity objects that are passed in via the context seem to be returned without augmenting them. AFAICS they should be combined with a key identifying the src of the generator and the validity of that src respectively in order to work.
Oh but I think I see now. The cache-key and cache-validity objects are associated with the compiled template object using template properties. The compiled template in turn is cached directly by the generator using the validity of the src of the generator. That should work.
So now how to use this feature. If I read this correctly cache-key and cache-validity attributes can be specified on an element anywhere in the xml:
<element jx:cache-key="${cacheKeyExpression}" jx:cache-validity="${cacheValidityExpression}" />
Yes it is. I am thinking about a slight change. Right now every xml node is parsed for jx:* attributes. What I would like to do is to introduce
<jx:processing instruction name="cache-key" value="${expr}"/>
wdyt?
Yes, I agree it would be better not to check each element for these attributes. <jx:processing-instruction/> sounds like a good option to me.
-- Unico
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
