cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [SUMMARY] Caching DynamicSelectionList
Date Mon, 30 May 2005 12:36:34 GMT
Antonio Gallardo wrote:

>On Lun, 30 de Mayo de 2005, 4:54, Sylvain Wallez dijo:
>  
>
>>Antonio Gallardo wrote:
>>    
>>
>>>THE SOLUTION
>>>============
>>>
>>>We found is posible to improve DSL performance by caching the DSL item
>>>data list once per request. The DSL remains dynamic per request.
>>>
>>>Caching DSL will not affect the current behaviour. The time for DSL
>>>generation will be reduced substancially.
>>>
>>>Our proposed solution is add a new user defined attribute, called "cache"
>>>in <fd:selection-list>. This way the cform user can decide when he wants
>>>to use a cached DSL or not. For SSL this attribute has no meaning.
>>>
>>>Posible values for @cache:
>>>
>>>true  - Cache SL content per request.
>>>false - No Cache SL content.
>>>
>>>default value: false.
>>>
>>>
>>>      
>>>
>>I'm wondering about the "cache" name which says nothing about the cache
>>duration, which is here the request. If we consider the behaviour of
>>dynamic="false", we can consider it as equivalent to cache="static"
>>(i.e. load once and never refresh).
>>
>>So IMO we should be deprecating dynamic="true" in favor of
>>cache="static|request".
>>    
>>
>
>IMHO in a DSL a "static cache" has no sense.
>  
>

Yes it does!

Actually DSL is a wrong term as it's not a "dynamic selection list" but 
a "selection list defined by a URL". And this URL can be a file, a 
remote ftp resource, the contents of a blob, or whatever resource that 
can be accessed with Cocoon protocols. Stating cache="static" means you 
load it once when the form definition is parsed and don't reload it 
later. This is exactly what currently happens with dynamic="false" (the 
default): the URL is fetched and the selection list created once for 
all, whatever protocol is used.

Lists defined by "cocoon:" are just a particular use case of the 
selection list defined by a URL for which we are likely to want reload 
to happen.

>Perhaps we can define:
>
>request-cache="yes|no" for DSL. And this is more explicit.
>
>I don't like this attribute is very implementation oriented. People will
>need to rewrite all the forms in order to take advantage of that. Well, it
>is very easy using jEdit...but... I think it is not too much dificult (and
>almost no time consuming) search ancestors looking for a Repeater.
>  
>

They don't need to rewrite: handling of the "dynamic" attribute can stay 
around for a while with the appropriate deprecation log.

And the attribute *has* to be implementation-oriented, as it is there to 
provide more control over the behavior of the implementation.

>Perhaps better is: request-cache="auto|yes|no"
>
>When the user don't this attribute in definition.xml it means he want a
>SSL, right?
>
>Wich will be the default behavior using:
>
>myWidget.setSelectionList(...);
>
>Here we cannot define the cache.
>
>I thought we can create a new method:
>
>myWidget.setCachedSelectionList(...);
>
>The more I think about this, I am more thinking the best is to make this
>automatically and let cocoon decide when use the cache or not.
>
>Another question: How to access the request attributes from
>DynamicSelectionList.java without touching another file? I cannot see how
>to get the FormContext from the DSL code.
>  
>

You can access the request from the Avalon context using ContextHelper, 
and a SelectionListBuilder can be made contextualizable.

>BTW, The code is almost done.
>  
>

Great!

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message