Antonio Gallardo wrote:
On Lun, 30 de Mayo de 2005, 4:54, Sylvain Wallez dijo:
Antonio Gallardo wrote:
THE SOLUTION
============
We found is posible to improve DSL performance by caching the DSL item
data list once per request. The DSL remains dynamic per request.
Caching DSL will not affect the current behaviour. The time for DSL
generation will be reduced substancially.
Our proposed solution is add a new user defined attribute, called "cache"
in <fd:selection-list>. This way the cform user can decide when he wants
to use a cached DSL or not. For SSL this attribute has no meaning.
Posible values for @cache:
true - Cache SL content per request.
false - No Cache SL content.
default value: false.
I'm wondering about the "cache" name which says nothing about the cache
duration, which is here the request. If we consider the behaviour of
dynamic="false", we can consider it as equivalent to cache="static"
(i.e. load once and never refresh).
So IMO we should be deprecating dynamic="true" in favor of
cache="static|request".
IMHO in a DSL a "static cache" has no sense.
Yes it does!
Actually DSL is a wrong term as it's not a "dynamic selection list" but
a "selection list defined by a URL". And this URL can be a file, a
remote ftp resource, the contents of a blob, or whatever resource that
can be accessed with Cocoon protocols. Stating cache="static" means you
load it once when the form definition is parsed and don't reload it
later. This is exactly what currently happens with dynamic="false" (the
default): the URL is fetched and the selection list created once for
all, whatever protocol is used.
Lists defined by "cocoon:" are just a particular use case of the
selection list defined by a URL for which we are likely to want reload
to happen.
Perhaps we can define:
request-cache="yes|no" for DSL. And this is more explicit.
I don't like this attribute is very implementation oriented. People will
need to rewrite all the forms in order to take advantage of that. Well, it
is very easy using jEdit...but... I think it is not too much dificult (and
almost no time consuming) search ancestors looking for a Repeater.
They don't need to rewrite: handling of the "dynamic" attribute can stay
around for a while with the appropriate deprecation log.
And the attribute *has* to be implementation-oriented, as it is there to
provide more control over the behavior of the implementation.
Perhaps better is: request-cache="auto|yes|no"
When the user don't this attribute in definition.xml it means he want a
SSL, right?
Wich will be the default behavior using:
myWidget.setSelectionList(...);
Here we cannot define the cache.
I thought we can create a new method:
myWidget.setCachedSelectionList(...);
The more I think about this, I am more thinking the best is to make this
automatically and let cocoon decide when use the cache or not.
Another question: How to access the request attributes from
DynamicSelectionList.java without touching another file? I cannot see how
to get the FormContext from the DSL code.
You can access the request from the Avalon context using ContextHelper,
and a SelectionListBuilder can be made contextualizable.
BTW, The code is almost done.
Great!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
