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 10:43:29 GMT
Leszek Gawron wrote:

> Unico Hommes wrote:
>
>> Unico Hommes wrote:
>>
>>> I am carrying this over to dev@ so other developers can comment.
>>>
>>> Leszek Gawron wrote:
>>>
>>>> Unico Hommes wrote:
>>>>
>>
>> <snip/>
>>
>>>>>
>>>>> 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.
>>>
>>
>> There is one other thing. The cache key that is returned by 
>> JXTemplateGenerator should be the src + jx:cache-key attribute value. 
>> Since the jx:cache-key is only a hash of the objects that are used in 
>> the template. These could, in theory, be the same as those objects 
>> used by another template. Therefore it is neccessary to also qualify 
>> the cache key with location of the template.
>>
> src/blocks/xsp/samples/java/cacheable.xsp:
>
>     /**
>     * Generate the unique key for the cache.
>     *
>     * This key must be unique inside the space of this XSP page, it is 
> used
>     * to find the page contents in the cache (if getValidity says that 
> the
>     * contents are still valid).
>     *
>     * This method will be invoked before the getValidity() method.
>     *
>     * @return The generated key or null if the component
>     *         is currently not cacheable.
>     */
>     public Serializable getKey()
>     {
>        // for our test, pages having the same value of "pageKey" will 
> share
>        // the same cache location
>        return "" + request.getParameter("pageKey");
>     }
>
> That is why I thought the key is considered only in one page space. Is 
> this example broken ?
>

Don't know, maybe XSP generator augments that key with the uri of the 
XSP source before it returns it to the pipeline If not, then the comment 
that the 'key must be unique inside the space of this XSP page' is not 
correct.

--
Unico

Mime
View raw message