W3C home > Mailing lists > Public > public-forms@w3.org > April 2011

Re: Submission Request-Response IDs (concurrent submit)

From: John Boyer <boyerj@ca.ibm.com>
Date: Mon, 4 Apr 2011 13:56:43 -0700
To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
Cc: public-forms@w3.org
Message-ID: <OFA096D6D6.57A5E1C4-ON88257868.0071492F-88257868.0073171A@ca.ibm.com>
It may be that "single concurrent submission" made it easy to untangle the 
responses, but I've never actually heard that offered as the example of 
why we kept the feature, so I think the transaction ID proposal won't fix 
the issue we were solving when we kept that feature.

As far as I can recall, the rationale was user-centric. It is easy to make 
a form that avoids multiple submission initiated by user impatience or 
user error.  Since there is currently no real submission progress 
indicator, a user may be inclined to press a submit or trigger a second 
time to activate a submission.  Or the user may just hit the submit or 
trigger twice as a slip of the finger.  Either way, the part of activation 
most likely to be associated with a billable event is the submission, and 
the current design ensures the user is not billed multiple times.

It's not that submission is the ideal place to make the restriction, so 
lifting the restriction could be fine if it were done in tandem with 
adding an *easy* way to prevent submit *and* trigger controls from running 
multiple submission transactions.

Cheers,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:   "Klotz, Leigh" <Leigh.Klotz@xerox.com>
To:     <public-forms@w3.org>
Date:   04/04/2011 11:51 AM
Subject:        Re: Submission Request-Response IDs (concurrent submit)
Sent by:        public-forms-request@w3.org



Nick van den Bleeken wrote:
>Currently the XForms spec doesn't allows this 'Under no circumstances
can more than a single concurrent 
>submit process be under way for a particular XForms submission'

Yes, that was there before the asynchronous submission, but when
asynchronous submission became part of the spec we retained it,
partially because of the issue that you cannot untangle the responses.
The transaction ID proposal is part of the fix.

Leigh.
Received on Monday, 4 April 2011 20:57:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:55 UTC