Re: Event marking and dispatch

I think that makes sense.

This said, I would much prefer if things worked differently, as you might
remember:

    https://www.w3.org/MarkUp/Forms/wiki/Improved_UI_Events

Given that we are rewriting things in a higher-level manner, maybe that
change could be included.

During refresh, we would say that:

- If a control's value (for controls which hold one) has changed since the
last refresh, then it dispatches the xforms-value-changed event.
- If a control's relevance, requiredness, readonliness, range, or validity
has changed, then it dispatches the appropriate MIP event.

There are a few edge cases:

- When a control becomes non-relevant, we might want to avoid dispatching
other MIP events and value changes.
- When a control becomes relevant, we have to decide whether we want to
dispatch any MIP/value events.
- For controls being created/deleted as a result of repeat iterations
added/removed, we need to specify the event behavior as well.

But other than that, that is it! I think that it makes things simpler, as
there is no discussion of node markings whatsoever. So we gain simplicity
and, I think, correctness and avoiding surprises to form authors.

-Erik

On Wed, May 10, 2017 at 7:51 AM, Steven Pemberton <steven.pemberton@cwi.nl>
wrote:

> During recalculate, the following events are marked for dispatch:
>
>  xforms-required or xforms-optional for required;
>  xforms-readonly or xforms-readwrite for readonly;
>  xforms-enabled or xforms-disabled for relevant.
>
> During revalidate the following events are marked for dispatch:
>
>   xforms-valid or xforms-invalid
>
> Then in refresh we say:
>
> "If the value of any bound instance data node has changed since the last
> refresh (such as by user interaction, a setvalue action, or as a result of
> a recalculate), then the xforms-value-changed event must be marked for
> dispatch to the bound controls, along with all of the appropriate model
> item property notification events (xforms-optional or xforms-required,
> xforms-readwrite or xforms-readonly, and xforms-enabled or xforms-disabled)
> that have also changed as a result."
>
> followed by
>
> "Marked notification events are dispatched to the controls bound to the
> nodes that originated the events. The notification events
> xforms-out-of-range or xforms-in-range must also be dispatched as
> appropriate. There is no defined ordering for the events."
>
> This seems poorly described.
>
> I think that recalculate should be responsible for marking:
>
>   xforms-required/optional
>   xforms-readonly/readwrite
>   xforms-enabled/disabled
>
> as at present, plus
>
>   xforms-value-changed
>
> revalidate should be responsible for marking:
>
>   xforms-valid or xforms-invalid
>
> refresh should be responsible for marking:
>
>   xforms-out-of-range/in-range
>
> and for dispatching them all.
>
> Agree?
>
> Steven
>
>