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 >>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 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. ;-) <snip> >>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.
