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 Thu, 02 Jun 2005 07:50:53 GMT
Antonio Gallardo wrote:

>On Mar, 31 de Mayo de 2005, 16:26, Joerg Heinicke dijo:
>  
>
>>Vadim's comments made me think again about the caching of selection
>>lists. And I don't think having a shorter cache period than a
>>form processing (as part of one request) makes no sense as it leads
>>to inconsistent forms when a selection list is reused.
>>    
>>
>
>Please explain. More this. Are you telling a cache life shorter than a
>request, makes or not makes sense?
>
>Sorry, for the above question. Too much negation on the sentence got me
>confused.
>
>  
>
>>Having this you *can* use time-based caching as you just
>>need to check the cache validity on first access to the source during
>>the form processing. During the form processing you always use the
>>same (buffered) selection list.
>>    
>>
>
>  
>
>>Now I can think of optimizations of the above when you only use a
>>selection list (or the source it is based on to be exact) once in a
>>form: there is no need for buffering.
>>    
>>
>
>Yep. I told that in one of my first mails. It can also be stated as:
>caching matter only inside a repeater.
>
>  
>
>>Can this be determined?
>>    
>>
>
>Yep. If (the selection-list widget has not a repeater as ancestor) OR
>((the selection list widget if has a repeater as ancestor) AND (the
>repeater has less than 2 rows)
>
>  
>
>>Now the other validity scopes. I do not have a real idea how to
>>configure it.
>>@cache="request|form|session|static"? (Is current "static" bound to form
>>    
>>
>instance or even longer? If it is the first it will be the same like
>what I had in mind with "form").
>
>1. per request (I have this already implemented on my HD, including the
>lastest comments about how to implement it).
>
>2. Per form, What I understand here is to cache all the selection-list and
>use the cache until the form is finished.
>
>3.per session. Valid while the user is logged in. Refreshed on each new
>login.
>
>4.static. As it is implemented now.
>
>About 2 and 3. I believe there are some usecases for them. What I am not
>sure is if the time effort vs. gain is important enough to add more
>complexity. Maybe, yes, but I will be glad to see them first. And check if
>this is OK.
>  
>

IMO the complexity is in setting up the cache mechanism. Adding new 
scopes (i.e. cache durations) is then mostly a matter of finding the 
right place to store the cached data.

>>Time based caching can be easily done on the pipeline as
>>we know or using the cached: pseudo protocol, but then you still
>>either have no buffered selection list sax events or you need
>>an object holding the buffer with the necessary lifetime.
>>    
>>
>
>Currently, I only create the buffer if there is the corresponding flag. I
>don't think it can create problems for time based cache.
>
>BTW, I don't committed, because I want to know the final keywords for
>@cache.
>

We can start with static and request, and add other values later.

>Are we going to deprecate @dynamic?
>  
>

Yes. Use of @dynamic should be logged as deprecated. Also, the default 
behavior should be changed to either cache="none" or cache="request", 
whereas today it's similar to cache="static".

Sylvain

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


Mime
View raw message