cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [SUMMARY] Caching DynamicSelectionList
Date Wed, 01 Jun 2005 14:01:57 GMT
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

> 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

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.

View raw message