Re: Asynchronous submission is the default?

Hi Erik,

Well, the discussion about why asynchronous submission became the default 
also covered the fact that it isn't good practice in XForms 1.0 to use a 
sequence of send actions where each submission launched by a send counts 
on the successful completion of its predecessor.

The reason is that you have no way to know whether the submission 
completed successfully or whether there was an error.  So the sequence is 
fragile.

The best practice is to put the send action that initiates a successor 
submission into the xforms-submit-done handler of its predecessor 
submission.  This way, if a submission fails, it does not continue with 
the sequence of submissions as if nothing went wrong.  Instead, the form 
does whatever the author specifies should be done to recover from the 
error.

This  best practice is also interesting because it works whether the 
submission is synchronous or asynchronous.

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
08/07/2007 03:55 PM
Please respond to
ebruchez@orbeon.com


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

Subject
Re: Asynchronous submission is the default?







John & all,

Well in our case (not a browser-based implementation) asynchronous is
more difficult than synchronous. This is probably the case for other
implementors, like Chiba. So there will be implementors for which one
or the other way is more difficult to implement. This is fine, as long
as we don't make it incredibly difficult (or even impossible) to
implement for a particular (and common) category of implementations.

But "natural" is relative. Sure, XHR does async. But we have quite
typical use cases where we send several submissions in sequence, one
needing the result of the the previous one. If async becomes the
default, all the submissions will have to be marked with
mode="synchronous", a clear incompatibility with XForms 1.0.

Maybe another solution would be to allow using xforms:submission as an
action: then, being in the flow of a series of actions, it would
naturally in this case default to synchronous, while a top-level
xforms:submission would still default to async. You would write things
like:

<xforms:action>
   <xforms:insert .../>
   <xforms:setvalue .../>
   <xforms:submission action="..." .../>
   <xforms:submission .../>
   <xforms:whatever .../>
</xforms:action>

-Erik

 > Hi Erik,
 >
 > First, to answer as an implementer, we also implemented synchronous
 > submission because this is what XForms 1.0 called for.
 >
 > I believe the issue was discussed in June 2006.  When it was discussed,
 > it turned out that many implementers who were building for client-side
 > web browsers did not believe that the spec said this.
 >
 > The spec says it quite clearly, and when faced with the text, the
 > response was that they assumed the spec was obviously in error since
 > asynchronous submission was more natural for the web and that it was
 > probably quite difficult for them to even implement synchronous
 > submission. This is my chance to reiterate that it is up to *all of us*
 > not to let the spec get out of synch with our reality like this.  If
 > anyone thinks the spec is wrong, it is more work to raise an issue but
 > we really need you to do so.
 >
 > Anyway, putting the process soapbox aside for the moment, the above
 > arguments caused the WG to decide that asynchronous should be the
 > default for 1.1.  I think that if implementer feedback suggests that
 > synchronous operation is indeed too hard to implement, then the
 > conformance section could reduce it to recommended (rather than the
 > current level of required).  But this feedback is most likely to occur
 > during CR.
 >
 > 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
 >
 > 08/07/2007 02:46 PM
 > Please respond to
 > ebruchez@orbeon.com
 >
 >
 > 
 > To
 >               "Forms WG (new)" <public-forms@w3.org>
 > cc
 > 
 > Subject
 >               Asynchronous submission is the default?
 >
 >
 > 
 >
 >
 >
 >
 >
 >
 > All,
 >
 > I notice in the current XForms 1.1 spec that the default value for
 > xforms:submission/@mode is "asynchronous". I am not sure why this is
 > the case. It seems that this is backward, but I may be mistaken. Did
 > we discuss this and was there a good rationale for using asynchronous?
 >
 > If you are to implement submission in XForms 1.0, say, it seem to me
 > that you would go with the more naive implementation and not bother
 > with asynchronism, as this will may require spawning another thread or
 > comparable mechanism.
 >
 > At least, that's the way we implement it in Orbeon Forms. What do
 > other implementations do?
 >
 > If it is the case that in 1.0 the default is (or is interpreted) as
 > synchronous, then shouldn't the default in XForms 1.1 be the same?
 >
 > -Erik
 >
 > --
 > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
 > http://www.orbeon.com/
 >
 >


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