Joerg Heinicke wrote:
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.
That's true. But that was the "instant, no additinal code required"
solution :-)
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.
I don't see why you consider it as pollution. Request attributes do
exist, and their purpose is to provide temporary storage for the various
things that participate in processing a request and are isolated either
in space (different classes) or time (same class called several times --
our case here).
Would it not be possible to have just one buffering
SelectionListHandler per source and request (or form) with an internal
SAXBuffer?
What would this handler do? Associate a buffered selection-list content
to a request? Then why not using request attributes?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
