W3C home > Mailing lists > Public > public-forms@w3.org > October 2009

xforms-value-changed event

From: Vlad Trakhtenberg <vladt@ca.ibm.com>
Date: Mon, 19 Oct 2009 09:36:28 -0700
To: www-forms@w3.org, public-forms@w3.org
Message-ID: <OF746CD2C4.6E26ADAA-ON88257654.0058D894-88257654.005B3B0B@ca.ibm.com>
Dear WG,
The XForms 1.1 spec defines :

4.4.3 The xforms-value-changed Event
Dispatched in response to: a change to an instance data node bound to a 
core form control.
Target: Core Form Controls
At the same time the section 8.1.1 has this language:
When a non-relevant form control changes to being relevant, the XForms 
action handlers that listen for events on the form control must become 
enabled and then the form control must be updated to represent the current 
value(s) and model item properties of the instance node(s) to which it is 
bound or to which it refers. The following events must be dispatched to 
the form control: xforms-enabled, xforms-value-changed, ...
Which means, in particular, that the xforms-value-changed event must be 
dispatched with or without change to it's bound instance data node.
And finally, if a form control bound instance node itself changes  - say 
as result of a change in predicate, use of a choose() function or 
insert/delete - and the new bound node's value is different from the value 
of the 'old bound node, the xforms-value-changed (and respective 
derivative events, like xforms-valid, etc.) is not supposed to be 
dispatched. This, arguably, makes it hard for form authors to trap changes 
that directly or indirectly affect the UI. 
These problems may have been discussed few times already, Hopefully, the 
next XForms revision will address them  - especially the last concern
Vlad Trakhtenberg, 
IBM, Victoria Software Lab 
Received on Monday, 19 October 2009 16:37:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:01 UTC