- 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 Thanks, Vlad Trakhtenberg, IBM, Victoria Software Lab
Received on Monday, 19 October 2009 16:37:05 UTC