Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Event handling in form libraries
Date: Sun, 4 Sep 2005 13:16:04 +0200
Message-ID: <A955EA1F8FE31749AEC8C998082F6C7C41A822@hai01.hippo.local>
Thread-Topic: Event handling in form libraries
Thread-Index: AcWwoWZ1siXF9Gs7S/6wa2S83KWQZwAnL1Cw
From: "Max Pfingsthorn" <m.pfingsthorn@hippo.nl>
To: <dev@cocoon.apache.org>

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
>=20
>=20
> Reinhard Poetz wrote:
>=20
> > 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=20
> related widgets=20
> >> with some interactions between them, e.g. a reusable car=20
> selector :-)
> >
> >
> > [Moving this discussion between Sylvain, Max and me to=20
> cocoon-dev as=20
> > it's of general interest]
> >
> > my wording was bad: I think they would make sense but I think the=20
> > implementation is a bit difficult or at least this can=20
> cause strange=20
> > errors. Maybe I'm wrong ...
> >
> > Here a simple example why I don't think that it can work=20
> with simply=20
> > 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=20
> libWidget2. And=20
> > if it had, how could the reference in the event handler=20
> code can work=20
> > as it probably has a different name than libWidget2 or is reused=20
> > several times in the form definition.
>=20
>=20
> Good point. We may allow on-change listeners in form=20
> libraries only in=20
> fields that aren't top-level, i.e. part of a group.
>=20
> Now aren't there any valid use cases where a field has an=20
> on-change that=20
> only acts on itself?
>=20
> Sylvain
>=20
> --=20
> Sylvain Wallez                        Anyware Technologies
> http://people.apache.org/~sylvain     http://www.anyware-tech.com
> Apache Software Foundation Member     Research & Technology Director
>=20
>=20