- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Mon, 19 Oct 2009 10:07:15 -0700
- To: www-forms@w3.org, public-forms@w3.org
Vlad, I am glad you are raising this. UI events in XForms must undergo a thorough review. It would be great if you could look at our draft proposal here: http://wiki.orbeon.com/forms/doc/developer-guide/xforms-refresh-events -Erik On Mon, Oct 19, 2009 at 9:36 AM, Vlad Trakhtenberg <vladt@ca.ibm.com> wrote: > 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 17:08:12 UTC