Antonio Gallardo wrote:
Hi:
Yesterday, I posted a simple RT on how to improve cforms dynamic selection
list performance. After getting a huge responses and a lot interest from
the cocoon dev list. :-)
Sorry for the late answer.
Your use case is perfectly valid and must be taken into consideration.
However, just as Joerg I have some reservations on the implementation ;-)
Caching the of the list data must not be triggered by the Field object,
for several reasons:
- the repeater containing the field may not be its direct parent, but
one of its ancestors if you have some enclosing group or union.
- each field in a repeater can programmatically be given a distinct
selection-list (e.g. with event handlers), in which case triggering the
test on the first repeater row will fail.
So this must be handled entirely either in the pipeline or in the
selection-list.
You're right in saying that a pipeline querying a database cannot easily
be cached. Now we have in the scratchpad (and this should IMO be
promoted to core) a nice "cached:" protocol, which allows to cache any
URI for a given period of time. So your DSL can use the
"cached:cocoon://database-query?cocoon:cache-expires=1" to have your
expensive pipeline called only once in a single second.
Caching in the selection-list itself can be done on a per-request basis
(thus ensuring the pipeline will be called only once per request), by
storing the selection list in a request attribute. The DSL has to
generate a unique attribute name (to avoid conflicts). When generating
the SAX fragment, either the attribute is empty and the pipeline is
called, caching on the fly, or the attribute exists and can be used
immediately. The cached value is then automatically trashed at the end
of the request processing.
How does that sound?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
