Re: Submission with instance replacement and deferred updates

John & all,

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

I agree.

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

In the synchronous case, I am not sure about what the expectations of
the form authors are, but my question is: why would one expect an
automatic recalculation after instance replacement but not in case of
xforms:setvalue or xforms:insert?

In an ideal world, you would probably want automagic updates happening
instantly all the time. But this seems impractical so we have decided
to go strongly the way of deferred recalculation and revalidation in
XForms 1.1, and I think we should do this in the most consistent
possible way rather than having exceptions to the rule here or there.

-Erik

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

Received on Wednesday, 25 July 2007 12:10:26 UTC