Re: Submission with instance replacement and deferred updates

Hi Erik,

Well, the more I think about it, the more I think that setting the 
rebuild-recalculate-revalidate-refresh flags for submission (rather than 
doing the actions) is not going to work at all for (instance replacement) 
asynchronous submission.

The reason is that it seems necessary for the asynchronous submission 
response handler to coordinate its actions with any running action handler 
via a mutex.  There is no way that an action handler should be "in 
progress" at the moment a submission response handler decides to replace 
an instance.  The submission response handler should wait until it is not 
in conflict with an action handler.  Otherwise, instability in the 
implementation is sure to result.

It also seems to cause problems with the author's expectations-- even with 
synchronous submissions.  The author of an xforms-submit-done event 
expects that the rebuild and recalculate has already occurred.  If we 
changed to just setting the flags, then the xforms-submit-done handler 
author has to decide whether rebuild and recalculate are necessary.  On 
the other hand, if nothing follows the submission, then this proposal does 
not actually optimize anything.

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

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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
07/23/2007 03:20 PM
Please respond to
ebruchez@orbeon.com


To
"Forms WG (new)" <public-forms@w3.org>
cc

Subject
Re: Submission with instance replacement and deferred updates







John Boyer wrote:
 >
 > Ah, good to know.
 >
 > But what do you think of Erik's idea here to *set* the deferred
 > update flags after submission, rather than doing the actions?
 >
 > I think I know where he is coming from... that a 'send' action could
 > be followed by further processing before
 > rebuild-recalculate-revalidate-refresh.
 >
 > This idea seems reasonable if submissions were synchronous, but the
 > fact that submission is asynchronous (by default) seems to be where
 > it falls down...

Good point, but it is still reasonable IMO to consider that all the
updates to instance data which occur in a synchronous way, whether
caused directly by actions or indirectly by a submission, use the
flags mechanism.

An asynchronous submission, on the other hand, could do one of two
things:

* Synchronously perform the refresh, etc. when it's done.

* However, this would be a waste if by any chance there is another
   sequence of actions/events (for example a synchronous submission
   still waiting to complete) at the same time for the same model. Not
   all implementations may allow this to happen. But if it is allowed,
   in that case, and with careful synchronization, the asynchronous
   submission could still set the flags.

The choice of how exactly this should be done could be left to the
implementor, the condition being that after the submission completes,
somehow, refresh, etc. must be performed.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/