Re: Deferred updates


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.


On Wed, Mar 29, 2017 at 10:53 AM Steven Pemberton <>

> "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)."
> Is there a purpose to dispatching the appropriate event, rather than just
> doing the rebuild or whatever?
> Steven
> --
Michael Odling-Smee | | m: +44 (0) 7946 512 754 |

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

Received on Wednesday, 29 March 2017 10:03:02 UTC