cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: Caching JXTemplate
Date Tue, 06 Jul 2004 09:35:52 GMT
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

Mime
View raw message