Re: Events after xforms-disabled

>
> The problematic case seems to be the last one, where the disabled event
> has to be synchronous.
>
> One possible solution would be to change xforms-enabled and
> xforms-disabled from being notification events, to making them events with
> effect, namely to enable or disable a control, and non-cancellable.
>
> Then the above scheme would look like this:
>
>     state=disabled & new-state=disabled:
>         do nothing
>     state=disabled & new-state=enabled:
>         dispatch enabled event
>         dispatch other events as necessary
>     state=enabled & new-state=enabled:
>         dispatch other events as necessary
>     state=enabled & new-state=disabled:
>         dispatch disabled event
>
> Thoughts?


During refresh, you update a control's binding: that's the moment where you
know that the control is changing from enabled to disabled, either because
 it is bound to a node with a non-relevant MIP, or because its binding
becomes empty. So you have to do 2 things during refresh in this case:

1. Update the control binding on the control object itself.
2. Dispatch an `xforms-disabled` event.

Currently, we do 1 then 2. It seems you would like to do 2 then 1, with 2
(the event dispatch) causing 1 (the update to the binding).

This means that the control object would still point to the old binding,
and then that the event should carry all the new binding information. Upon
target phase, or default action, the control would receive this information
and update its binding.

I see some issues with that:

- As you dispatch a first `xforms-disabled` to a first control, an event
handler for that event will have a view of the tree of controls which is
not yet up to date.
- This would be different from the other UI events, which would presumably
just be notifications. That's a consistency issue.
- But then `xforms-enabled` by symmetry should work the same. What about
other UI events?
- That seems more complicated than it should be (see the simple solution
below).

I think it is much easier to dispatch the `xforms-disabled` event to the
control, even if is already disabled. Event dispatch being a DOM feature,
the DOM doesn't care that the underlying control object doesn't have
behavior anymore, and there is nothing that prevents the event from being
targeted at the DOM element and handle catpure, target and bubbling phases
as usual.

I also like the simplicity of these two steps:

1. Update the tree of controls. This is an indivisible operations. All
controls are in the old state, and then all controls are in the new state.
There are no events dispatched at that time so no opportunity for event
handlers to have an inconsistent view of the world.
2. Dispatch notification events.

-Erik