Re: xforms-refresh

On Mon, 21 Nov 2016 19:12:31 +0100, Erik Bruchez <ebruchez@orbeon.com>  
wrote:

> 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*

Well, I'm interested to hear you say that. It seems eminently sensible  
frankly. Alain, any comments?

Steven

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