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
