W3C home > Mailing lists > Public > public-xformsusers@w3.org > November 2016

Re: xforms-refresh

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Mon, 21 Nov 2016 10:12:31 -0800
Message-ID: <CAAc0PEW5eem4e=8r46jFtRcpUNQGbTHWJu+T0KmH7nD_tgVtBQ@mail.gmail.com>
To: Steven Pemberton <steven.pemberton@cwi.nl>
Cc: "public-xformsusers@w3.org" <public-xformsusers@w3.org>
This takes us back to the (unfortunately) aborted project of revisiting UI


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


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.


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

> 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
Received on Monday, 21 November 2016 18:13:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:47 UTC