Re: Deferred updates

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