cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <m.pfingsth...@hippo.nl>
Subject RE: Event handling in form libraries
Date Sun, 04 Sep 2005 11:16:04 GMT
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:sylvain@apache.org]
> Sent: Saturday, September 03, 2005 18:06
> To: dev@cocoon.apache.org
> 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
> 
> 

Mime
View raw message