cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [RT] Cforms selection-lists
Date Sun, 29 May 2005 10:37:34 GMT
On Dom, 29 de Mayo de 2005, 3:21, Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>>On Sab, 28 de Mayo de 2005, 7:45, Sylvain Wallez dijo:
>>>Antonio Gallardo wrote:

> No problem. You have a need, you explain it and start implementing, and
> we discuss :-)

Hehe! :-S

>>>- 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
> :-)
>>>So this must be handled entirely either in the pipeline or in the
>>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 sure we need something like that, I think the best is if cocoon will
decide when to use cache. Giving to the end user the choice to set or not
@cache in the SelectionList will end up in mistakes (ie: unnecesary cache
setup or missing @cache when is really needed). I can even see the mails
on the user list. Hmm... I also understand this is a 1st step. And we can
left this for the future, but I don't like this idea,.... but.... if there
is not another option, then I can live with a new attribute. We don't have
a choice. :-( Perhaps the builder can take care of this? Is this posible?
I know it is posible, but I mean in a way to not break the code again! You
know what I mean. ;-)

Well, lets start by the new optional @cache. In fact this was one of my
first ideas, before I realized that cforms should do that for us. ;-)


>>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()"?

It's OK to me.

>>How we are going to implement this? Can you do this?
> Better do it yourself if you need it quicly :-)

It's OK (again!) :-S

> Don't hesitate to ask if you need advices however!

Thanks! :-)

Best Regards,

Antonio Gallardo.

View raw message