Antonio Gallardo wrote:
On Sab, 28 de Mayo de 2005, 7:45, Sylvain Wallez dijo:
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.
Opss. I forgot this! Hence, the current implementation is buggy and needs
to be changed. I will revert the changes now. Sorry for the disturb.
No problem. You have a need, you explain it and start implementing, and
we discuss :-)
- 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.
Yes. This is what I already saw. This address my second concern related to
setting programatically a new SelectionList inside an event. Somehow, we
need to cache this too, because inside a repeater there is a big chance we
are using the same SelectionList over and over. Again, this is place for a
performance improvement.
My proposal also handles this case. If the DSL object manages the
caching by itself, caching also happens if the same DSL object is set
programmatically on various objects.
And this applies to more uses case than a repeater, but also to more
complicated use cases such as recursive forms, e.g. a sitemap editor
where the list of generators will be attached to all widgets
representing a <map:generate>
Given this new facts, I started to think if is posible to have a cache
Collection of all involved DSL list (perhaps implemented as a handler, as
suggested by Joerg). The handler will check first inside the cache
Collection is the SelectionList was already generated.... Bah! Your
solution suggested below is far better than this one. Dropping this
idea...
:-)
So this must be handled entirely either in the pipeline or in the
selection-list.
I don't like the pipeline idea. Better at the selection-list.
But I see again teh selection-list needs to know more info, to create a
smarter cache. We need to cache only if needed. If not, then we will
slowdown the other selection-list that don't need an attribute after all.
So let's add a "cache" attribute on <fd:selection-list> that, if true,
will enable the caching.
For example, If we have only a SelectionList in a form without a repeater
or in a form with repeater but the SelectionList is placed outside the
repeater, then there is totally not sense to cache the info. It is only a
waste of time and memory.
Yep.
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.
I think this is the best. And this is what I will be glad to see this
working! :-)
How does that sound?
This last suggestion, is really great! As you told, we need to find a way
to generate a real unique attribute name to avoid conflict with whatever
other attributes inside the request.
What about "new java.rmi.server.UID().toString()"?
How we are going to implement this? Can you do this?
Better do it yourself if you need it quicly :-)
Don't hesitate to ask if you need advices however!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
