On 28.05.2005 14:45, Sylvain Wallez wrote:
So this must be handled entirely either in the pipeline or in the selection-list.
+1
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.
This might lead to inconsistent forms as the form request processing is not synchronized with this caching.
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.
"Polluting" the request is always something to be avoided as far as possible IMO. Would it not be possible to have just one buffering SelectionListHandler per source and request (or form) with an internal SAXBuffer?
Joerg
