cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
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
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.


Mime
View raw message