Re: Deferred updates

Eric,

Thanks for your detailed explanation.

I think as a form author it is point 2 that causes some pain.

It means that a form author - even though they are using a declarative
language - has to understand some possible concurrency issues, and insert
<recalculate/> to flush the values. This is a subtlety that I think most
form authors - particularly those from a development background - would not
expect (as a sample of one I was caught out by it). The upshot is the
deferred update requires potential XForm authors to have a very detailed /
low level understanding of the specification.

Mike

On Wed, Mar 29, 2017 at 3:16 PM Erik Bruchez <ebruchez@orbeon.com> wrote:

> Michael,
>
> I think there are two aspects to this:
>
> 1. whether we want to talk about flags in the spec
> 2. whether changes in the data model are "instant"
>
> On point 1, we agree and we will make the spec a little less prescriptive.
>
> One point 2, there is a deeper impact. For example:
>
>     <a>0</a>
>     <b>1</b>
>     <c/>
>
>     <bind ref="b" calculate="../a + 1"/>
>
>     <action>
>       <setvalue ref="a" value="42"/>
>       <setvalue ref="c" value="../b"/>
>     </action>
>
> Right now recalculation and revalidation are deferred, which means that
> after the action runs, the data will be:
>
>     <a>42</a>
>     <b>1</b>
>     <c>1</c>
>
> Eventually, at the latest just before the UI refreshes, the data becomes:
>
>     <a>42</a>
>     <b>43</b>
>     <c>1</c>
>
> If you want, as of the second `<setvalue>`, calculations to be up to date,
> you have to do:
>
>     <action>
>       <setvalue ref="a" value="42"/>
>       <recalculate/>
>       <setvalue ref="c" value="../b"/>
>     </action>
>
> and then the result is:
>
>     <a>42</a>
>     <b>43</b>
>     <c>43</c>
>
> Now it is unclear at this point whether we want to change the XForms
> processing model to do this kind of instant reactive changes. They appear
> to have an impact only on sequences of actions like the one shown above.
> But I am not sure if you are suggesting that XForms should do that.
>
> -Erik
>
> On Wed, Mar 29, 2017 at 5:34 AM, Steven Pemberton <steven.pemberton@cwi.nl
> > wrote:
>
> A good point, and I tend to agree with you: the spec seems to be somewhat
> over-specified on this point, so that implementation issues poke through
> when they shouldn't
>
> We'll discuss it this afternoon.
>
> Thanks for the comment.
>
> Steven
>
>
> On Wed, 29 Mar 2017 12:02:19 +0200, michael odling-smee <
> michael.odling-smee@xml-solutions.com> wrote:
>
> All,
>
> Just an observation from an end user.
>
> I have never really understood the need for deferred updates - is it still
> required with modern technologies (browsers)? It seems like a premature
> optimisation that should probably not be part of the specification (but
> could still be within an implementation). Certainly from a declarative
> programming point of view it seems strange to have to consider update
> concurrency - e.g. a value was set via an <xf:setvalue .../> in one part of
> the form which updates a value in the instance that is used in a
> calculation elsewhere (possibly within the same user action). As a form
> author it seems I have to worry about whether the new value has been
> applied in time for the calculation - the outcome of which may affect
> behaviour for the end user.
>
> Mike
>
> On Wed, Mar 29, 2017 at 10:53 AM Steven Pemberton <steven.pemberton@cwi.nl>
> wrote:
>
> "A deferred update for a model consists of examining each deferred update
> flag in the order of rebuild, recalculate, revalidate, and refresh, and
> for each that is set, clearing it and dispatching the appropriate event to
> the model (i.e. dispatch xforms-rebuild for a rebuild flag, and so on)."
> https://www.w3.org/community/xformsusers/wiki/XForms_2.0#Deferred_Updates
>
> Is there a purpose to dispatching the appropriate event, rather than just
> doing the rebuild or whatever?
>
> Steven
>
> --
> --
> Michael Odling-Smee | mike@xml-solutions.com | m: +44 (0) 7946 512 754
> <+44%207946%20512754> | www.xml-solutions.com
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery. NOTE: Regardless of content, this e-mail shall not operate to
> bind XML Solutions Ltd to any order or other contract unless pursuant to
> explicit written agreement or government initiative expressly permitting
> the use of e-mail for such purpose.
>
> Address: Newlaithes Manor, Newlaithes Road, Horsforth, Leeds LS18 4LG.
> Registered Company Number: 6233174
>
>
>
>
>
> --
-- 
Michael Odling-Smee | mike@xml-solutions.com | m: +44 (0) 7946 512 754 |
www.xml-solutions.com

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind XML Solutions Ltd to any order or other contract unless pursuant to
explicit written agreement or government initiative expressly permitting
the use of e-mail for such purpose.

Address: Newlaithes Manor, Newlaithes Road, Horsforth, Leeds LS18 4LG.
Registered Company Number: 6233174