Re: [SUMMARY] Caching DynamicSelectionList

[Antonio Gallardo <ag...@agssa.net>]

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.

> 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. Are we going to deprecate @dynamic?

Best Regards,

Antonio Gallardo.

Re: [SUMMARY] Caching DynamicSelectionList

[Joerg Heinicke <jo...@gmx.de>]

Antonio Gallardo <agallardo <at> agssa.net> writes:

> > 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?

Makes no sense. But not a request, only the processing phase of one form to be
exact.

> Sorry, for the above question. Too much negation on the sentence got me
> confused.

I like it  ;-)

> > 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.

No, different selection lists might be based on one source. They must be equal
though.

> > 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)

No, see above (repeater is not sufficient). :-)

Joerg

Re: [SUMMARY] Caching DynamicSelectionList

[Antonio Gallardo <ag...@agssa.net>]

On Jue, 2 de Junio de 2005, 2:50, Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>>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".

Just committed:

Cforms block: Caching selection list for best performance inside
repeaters. Deprecate @dynamic in <fd:selection-list>  in favor of @cache.
Posible @cache values are:

        * static => equivalent to old @dynamic="false"
        * none => equivalent to old @dynamic="true"
        * request => is new, similar to cache="none", but caching the
selection list per request. Useful to improve performance inside
repeaters.

Defaults are the same as before.

                                  - 0 -

Now looking forward, the next task is improve the SelectionLIst
performance, when it is created using:

<fd:on-value-changed>
 <fd:javascript>
   var value= ....
   myWidget.setSelectionList("cocoon:/mySelectionList?id=" + value);
   .....
 </fd:javascript>
</fd:on-value-changed>

Thanks for all the help provided! ;-)

Best Regards,

Antonio Gallardo.

Re: [SUMMARY] Caching DynamicSelectionList

[Sylvain Wallez <sy...@apache.org>]

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