Re: Submission and deferred update [Re: XForms - Submission on multiple instances?]

Hi Mark,

The new text in 1.1 says that it performs the rebuild, recalculate, 
revalidate, refresh, not that it defers them.
It says it is related to deferred update because performing the operations 
clears the deferred update flags.

Deferred update is an *extra* set of 
rebuild/recalculate/revalidate/refresh operations that happens 
automatically at the end of an action sequence.  Executing certain actions 
sets the flags, but performing an actual rebuild, recalculate, revalidate 
or refresh clears the corresponding flag(s).

There is an important related point, though, about reasonable expectations 
after a send action has been executed.

As written in XForms 1.0, the response to the submission is handled as 
part of the default event processing for xforms-submit.  Since the send 
action dispatches the xforms-submit, it should be the case that actions 
running after the submit 

However, many implementers have implemented submission as an asynchronous 
operation in which the first four steps of xforms-submit default 
processing are performed, but the final step of processing the result 
happens later, whenever the result of the submission is obtained.  This 
means that actions after a send must not count on the results of the send 
being available.

In truth, form authors should not have been doing so anyway because you 
cannot count on the results of a send unless the submission ended without 
error, which you cannot detect after a "synchronous" send, except by 
application-specific means,  Therefore, regardless of whether the XForms 
processor has implemented synchronous or asynchronous submissions, the 
form authors should put post-processing behavior in the handler for 
xforms-submit-done.

John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Mark Birbeck" <mark.birbeck@x-port.net> 
Sent by: www-forms-request@w3.org
11/01/2006 02:10 AM
Please respond to
mark.birbeck@x-port.net


To
www-forms@w3.org
cc

Subject
Submission and deferred update [Re: XForms - Submission on multiple 
instances?]







Hi John,

> To reiterate, Section 11.1, point 5, bullet 2.
> The instance replacement of submission is followed immediately by 
*rebuild*,
> recalculate, revalidate, *refresh*.

It's true that the Second Edition spec is a bit clearer on the intent,
and the part you refer to says this:

  Once the XML instance data has been replaced, the rebuild, recalculate,
  revalidate and refresh operations are performed on the model, without
  dispatching events to invoke those four operations. Submit processing
  then concludes after dispatching xforms-submit-done.

That's a little clearer than the first edition, which said this:

  [T]he response is parsed as XML and all of the internal instance data
  corresponding to the submitted instance is replaced with the result,
  using the same processing as remote instance data retrieved through
  src, and the xforms-model-construct event is dispatched to element
  model. Submit processing then concludes after dispatching
  xforms-submit-done.

> These are *not* deferrred update behaviors after some action (submission 
is not an
> action; send is an action, but all it does is *initiate* a submission).
> The rebuild, recalculate, revalidate, refresh are mandatory behaviors 
that occur *before*
> xforms-submit-done is dispatched.

Although submission is not an action, it can only 'do its thing'
within an action handler. And since, according to 10.1.1, this:

  <xf:action ...>
    <xf:send ... />
  </xf:action>

will have deferred update behaviour, it seems that this in effect
'overrides' the update behaviour in 'send'.

Now, you could say that this is just an ambiguity, and that it's not
really clear which should take priority--the deferred update, or
performing RRRR immediately--so I took a look at your latest XForms
1.1 draft, to see if you'd made it more explicit , and I discovered
that it now says this:

  Once the XML instance data has been successfully  replaced, the rebuild,
  recalculate, revalidate and refresh operations are performed on the 
model,
  without dispatching events to invoke those four operations. This 
sequence of
  operations is associated with special deferred update behavior. 
Submission
  processing then concludes after dispatching xforms-submit-done with
  appropriate context information.

On other words, the additional second sentence seems to make it even
clearer that the RRRR is subject to deferred update!

I thought it worth flagging up.

Regards,

Mark

-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/