- From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
- Date: Thu, 13 Sep 2007 11:13:16 -0500
- To: ebruchez@orbeon.com
- CC: www-forms-editor@w3.org
Erik, 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 model. Regards, 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