W3C home > Mailing lists > Public > public-forms@w3.org > May 2007

Re: Value changes upon instance replacement

From: Joern Turner <joern.turner@dreamlab.net>
Date: Tue, 22 May 2007 14:05:43 +0200
Message-ID: <4652DC97.2030406@dreamlab.net>
To: ebruchez@orbeon.com
CC: public-forms@w3.org, www-forms-editor@w3.org

I completely agree. Behavior after an instance replacement is 
inconsistent with the rest of the processing model and should be aligned 
to dispatch the value-change sequence.

Joern

Erik Bruchez wrote:
> 
> 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
> 
Received on Tuesday, 22 May 2007 14:43:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:43 UTC