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.
