cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Cforms selection-lists
Date Sat, 28 May 2005 12:45:12 GMT
Antonio Gallardo wrote:

>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 

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 Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message