W3C home > Mailing lists > Public > www-forms-editor@w3.org > September 2007

Re: Value changes upon instance replacement (PR#50)

From: (wrong string) é <xforms-issues@mn.aptest.com>
Date: Thu, 13 Sep 2007 11:13:16 -0500
Message-Id: <200709131613.l8DGDGRq010801@htmlwg.mn.aptest.com>
To: ebruchez@orbeon.com
CC: www-forms-editor@w3.org


we recognize the problem, but defer changes to MIP events for now because we
need a broader based redesign of events for controls and possibly also for

Ulrich Nicolas Lissé

For the Forms WG> All,
> At the moment, I don't think this is clearly specified to happen.
> Use case:
> 1. <xforms:input ref="name">
> 2. The instance containing "name" is replaced.
> 3. Section 11.2 specifies that a refresh must take place. However, no
>      node of the new instance is marked as having changed as I
>      understand it. 4.3.4 says "If the value of an instance data node
>      was changed, then the node must be marked for dispatching the
>      xforms-value-changed event.". But in this case, the value of the
>      node hasn't changed because the node is just freshly created from
>      the instance replacement.
> 4. Consequence: no xforms-value-changed is fired.
> This behavior is very non-intuitive because you can replace an
> instance under controls' feet and while the control may update their
> values in the UI, no xforms-value-changed is fired.
> This means that you cannot reliably use events to determine if the
> value of a control has changed or not. I think that this should be
> possible, or the usefulness of value-changed-events is greatly
> reduced.
> -Erik
> -- 
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
Received on Thursday, 13 September 2007 16:14:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:12 UTC