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

RE: Cancel a submission in progress

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Thu, 6 Apr 2006 19:15:41 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF401B2BE8F@usa7061ms01.na.xerox.net>
To: <www-forms@w3.org>, "Steven Pemberton" <steven.pemberton@cwi.nl>, "David Landwehr" <david.landwehr@solidapp.com>, "Allan Beaufour" <beaufour@gmail.com>
Cc: "Klotz, Leigh" <Leigh.Klotz@xerox.com>

The error case should read
  <group ref="error">
     <action event="xforms-value-changed"> 
       <load resource="/cgi-bin/apologize" />
     </action>
     Failed to place your order, due to error <output ref="@code"/>:
<output ref="message" />
  </group>

Sorry for cut-and-paste.
Leigh.

-----Original Message-----
From: Klotz, Leigh 
Sent: Thursday, April 06, 2006 5:05 PM
To: Steven Pemberton; David Landwehr; Allan Beaufour
Cc: www-forms@w3.org; Klotz, Leigh
Subject: RE: Cancel a submission in progress

There's a few issues surrounding life after submission.
Cancelling a submission is one; HTML4 current browsers allow users to do
this usually with an out-of-frame big STOP button, but that's not
programmable and it's not clear what it does to the asynchronous XML
submissions that are popular these days.

Here are two related issues about submission and errors that are vexing
me today:

1. xforms-submit-error is signalled both when submission fails to happen
and when the server responds with a failure.
The two cases are indistinguishable for the form, and that leads to
mayhem, as I noted on April 3rd, 2006:
>From: Leigh.Klotz@xerox.com
>Subject: RE: What to do with a 404 on a submission replace="all"?
>On a related topic, I wish there were a way to distinguish 
>server-reported errors such as the 404) from processor-generated errors
(such as missing required fields).
>Presumably this will come with the context info, but it would probably 
>be useful even to separate them at gross level.  As it is, a form that 
>catches xforms-submit-error can't do much with it.  And if the 
>processor reports validation or required field errors on its own (such 
>as by highlighting missing fields), then the xforms-submit-error is a
true annoyance.

So my conclusion is that intentionally sending back HTTP error codes is
just not a good practice with XFOrms 1.0, and instead we need to return
error documents.

2. Error Documents
Let's suppose your form does a submission with replace=instance, but the
server decides that there was an error and wants to report it to the
user.  In HTML4 forms, there is only replace=all, and so the server
simply responds with a new XHTML, HTML4 or text/plain document which the
UA displays.  

In XHTML+XForms, though, that would result in the instance being
replaced with a UI page, or more likely an xforms-submit-error because
of bad instance content.

So, let's suppose you decide to do the right thing, and return either a
success document that looks like this:
   <object uid="123"><title>Broccoli</title></object>
Or an error document that looks like this:
   <error code="259"><message>You must parsify before
dessicating.</message></error>

A form author can code two groups:
  <group ref="object[@uid]"> Ordered your <output ref="title"/></group>
  <group ref="error">Failed to place your order, due to error <output
ref="@code"/>: <output ref="message" /></group>

3. So far so good, but what happens if you want to offer a new page
instead of a new view (i.e., you really want to change your mind and do
a replace=all with a new URI).  How can you perform xf:load differently
in the two cases without putting the new resource URI into the returned
instance, which inappropriately mixes data and presentation?

Is xforms-value-changed or xforms-enabled supposed to work for this?

xforms-enabled:
  <group ref="object[@uid]"> 
     <action event="xforms-enabled">
       <load resource="/cgi-bin/thank-you" />
     </action>
     Ordered your <output ref="title"/>
  </group>
  <group ref="error">
     <action event="xforms-value-changed"> 
       <load resource="/cgi-bin/thank-you" />
     </action>
     Failed to place your order, due to error <output ref="@code"/>:
<output ref="message" />
  </group>

Or with xforms-value-changed

  <group ref="object[@uid]"> 
     Ordered your 
      <output ref="title">
        <action event="xforms-value-changed">
          <load resource="/cgi-bin/thank-you" />
        </action>
      </output>
  </group>
  <group ref="error">
     Failed to place your order, due to error 
     <output ref="@code">
       <action event="xforms-value-changed"> 
           <load resource="/cgi-bin/thank-you" />
       </action>
     </output>
     <output ref="message" />
  </group>



-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Steven Pemberton
Sent: Tuesday, April 04, 2006 8:37 AM
To: David Landwehr; Allan Beaufour
Cc: www-forms@w3.org
Subject: Re: Cancel a submission in progress


I think it's a great idea for stopping those long waits for slow servers
when you realise you've sent the wrong data anyway...

Here's my pattern for this:
...
Received on Friday, 7 April 2006 02:16:25 GMT

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