xforms-value-changed event

[Vlad Trakhtenberg]

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

[Erik Bruchez]

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@...> 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