W3C home > Mailing lists > Public > www-forms@w3.org > June 2006

Re: XForms submission: synchronous?

From: Mikko Honkala <honkkis@tml.hut.fi>
Date: Thu, 15 Jun 2006 12:20:50 +0300
Message-ID: <44912672.8010509@tml.hut.fi>
To: John Boyer <boyerj@ca.ibm.com>, www-forms@w3.org

Hi John,

I don't agree that submission is synchronous in the spec. This is a bit 
unclear in the spec, although most implementers have implemented it 
asynchronously (similar to AJAX). There is text in the spec regarding to 
simultaneous ongoing submissions, which hint in the asynchronous direction.

The xforms-submit-done is the hook for the author.

In my opinion xforms:submit does not block. It just starts the 
submission and returns immediately. That has to be cleared in the spec. 
Most browsers are event queue-based anyway, so no two actions/scripts 
are ever run simultaneously, except for ongoing submissions.

-mikko

John Boyer wrote:
>
> Current XForms 1.0 reads that submission is synchronous
> because DOMActivate on trigger "dispatches" xforms-submit.
>
> The spec does not say "(may|should|must) launch a separate
> thread to dispatch" xforms-submit.
>    
> Then, xforms-submit capture, bubble and default processing
> occur.  The default processing then describes the occurrence
> of the entire submission down to done or error.
>
> Therefore, it is currently reasonable for an XForms author to
> assume that a send action which does an instance replacement
> will actually replace the instance before the next action after
> the send occurs.
>
> To be fair, it would be *better* for that author to write the follow-on
> actions after a send action into the xforms-submit-done handler
> in order to ensure that the follow-on actions occur only if the
> submission is successful.  And if this is done, then the resulting
> form would operate correctly whether submission is synchronous
> or asynchronous.
>
> Moreover, there's a lot of benefit to being asynchronous, and some
> implementations at least have already gone that route despite what
> the spec says, so this email is being sent to promote discussion
> about the issue so we can get alignment, either for 1.0 or 1.1.
>
> In particular, it was stated here at the FtF that the option of 
> synchronicity
> was deliberately left open so as not to preclude implementation on
> small devices.  So, clearly the language should be that a submissoin
> MAY be asynchronous.
>
> Moreover, if a submission is asynchronous, then how far into the
> process does it get while still blocking the initiating thread?  In other
> words, is the whole dispatch of xforms-submit done by a separate thread?
> Or do we only branch to a separate thread some time after taking a
> snapshot of the data to be submitted?   Otherwise, the sufficiently
> talented user could change the data between the point where we
> prune and validate and the point where the data is transmitted.
>
> John M. Boyer, Ph.D.
> Senior Product Architect/Research Scientist
> Co-Chair, W3C XForms 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
>
Received on Thursday, 15 June 2006 09:24:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:05 GMT