Hi! Okay, I see what you mean, but as a user of such a library, you have to be aware of what it requires. In my conception, the usecase you describe is not valid as you try to use only a part of an obviously connected set of widgets. You can do this, however you have to override the event handler in the inheriting widget. This would solve your problem just fine and allow for specifying complex widget structures in a library.
I think we shouldn't impose restrictions on the use of libraries and specific parts of widgets within libraries. As long as it is "fixable" by adding a line or two in your definition and being a bit more aware of what you are inheriting from, this should be fine, right? Additionally, as Sylvain pointed out, there are valid uses of event handlers in top-level library widgets... i.e. on-change for an auto-completing text field via ajax (?). The thing is that even if we don't impose anything, we can still support encapsulating reusable parts, like the car selector or some metadata, in libraries (and promote this as a good practice in the docs). I think, we would be limiting the possibilities of the libraries if we treated them any different than a normal form definition. Bye! max > -----Original Message----- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 03, 2005 18:06 > To: [email protected] > Subject: Re: Event handling in form libraries > > > Reinhard Poetz wrote: > > > Sylvain Wallez wrote: > > > >>> - event handlers in libraries are allowed, but I don't think they > >>> make sense there (e.g. on-value-changed) > >> > >> > >> Why not? A library may for example contain a group of > related widgets > >> with some interactions between them, e.g. a reusable car > selector :-) > > > > > > [Moving this discussion between Sylvain, Max and me to > cocoon-dev as > > it's of general interest] > > > > my wording was bad: I think they would make sense but I think the > > implementation is a bit difficult or at least this can > cause strange > > errors. Maybe I'm wrong ... > > > > Here a simple example why I don't think that it can work > with simply > > using the eventhandler code of the library in the form definition. > > > > LIBRARY > > > > libWidget1 has eventhandler that references libWidget2 > > libWidget2 > > > > FORM DEFINITION (imports above library) > > > > myWidget1 extends libWidget1 > > > > What happens now? The form doesn't has a reference to > libWidget2. And > > if it had, how could the reference in the event handler > code can work > > as it probably has a different name than libWidget2 or is reused > > several times in the form definition. > > > Good point. We may allow on-change listeners in form > libraries only in > fields that aren't top-level, i.e. part of a group. > > Now aren't there any valid use cases where a field has an > on-change that > only acts on itself? > > Sylvain > > -- > Sylvain Wallez Anyware Technologies > http://people.apache.org/~sylvain http://www.anyware-tech.com > Apache Software Foundation Member Research & Technology Director > >
