Re: xforms-value-changed event


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:


On Mon, Oct 19, 2009 at 9:36 AM, Vlad Trakhtenberg <> 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