cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: Caching JXTemplate
Date Tue, 06 Jul 2004 09:24:47 GMT
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?

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message