Re: xforms-refresh

This takes us back to the (unfortunately) aborted project of revisiting UI
events:

    https://lists.w3.org/Archives/Public/public-forms/2007Jun/0030.html

We implement a different behavior for UI events in our implementation:

    https://doc.orbeon.com/xforms/events-refresh.html

Following that, the change events are only dispatched:

- for non-default property values when the control becomes relevant (and
that could be revisited)
- when the properties actually change *from the perspective of the control*

So I don't know about use cases, but I think that it doesn't make sense to
dispatch change events when things haven't changed.

-Erik

On Fri, Nov 18, 2016 at 11:59 AM, Steven Pemberton <steven.pemberton@cwi.nl>
wrote:

> https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The
> _xforms-refresh_Event
>
> "If the xforms-value-changed event is marked for dispatching, then all of
> the appropriate model item property notification events must also be marked
> for dispatching (xforms-optional or xforms-required, xforms-readwrite or
> xforms-readonly, and xforms-enabled or xforms-disabled)."
>
> However, xforms-recalculate goes to a lot of trouble to only mark such
> events for dispatch if the property has changed.
>
> Is there a use case for sending (xforms-optional or xforms-required,
> xforms-readwrite or xforms-readonly, and xforms-enabled or xforms-disabled)
> when the value has changed, but the property hasn't?
>
> Steven
>
>