RE: Submission and protocol 'errors' [was RE: Cancel a submission in progress]

I agree that conditional actions and access to results from HTTP
submissions, including response code and data payload, is a good
all-around addition to XForms 1.1 submission and I supported it even for
XForms 1.0, but the design and dicsussion was not completed because of
time constraints. 

However, I believe that it's possible to handle this condition (at least
for result code=200 cases) in XForms 1.0, and that making sure that this
works in current processors will go a long way towards getting what we
want in XForms 1.1 as well.

Here is a test case for using <submission replace="instance"> and two
<group> elements, one bound to "/data" and one bound to "/error".  Only
one of these will get shown, and accordingly only one of them will get
an xforms-enabled dispatched to it (or as Allan suggests, an
xforms-value-changed).

I've tried this technique in some XForms 1.0 user agents and it works,
but fails in others.
(Actually, in Mozilla XForms 0.4 I get 2 copies of "Success" an 4 copies
of "Error" but that counts as works. The difference may be due to the
varying parent of xf:action; I haven't explored it.)

This example depends on the xforms-enabled event being dispatched to
form controls that become relevant due to the appearance of nodes; the
nodes, of course, appear as a result of submission/@replace='instance'.

Leigh.

<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xf="http://www.w3.org/2002/xforms"
xmlns:ev="http://www.w3.org/2001/xml-events">
  <head>
    <title>XForms Enabled Test</title>
    <xf:model>
      <xf:instance>
        <data xmlns="">
          <b>0</b>
        </data>
      </xf:instance>
      <xf:submission id="loadABC" method="get" action="abcdata.xml"
replace="instance" />
      <xf:submission id="loadError" method="get" action="error.xml"
replace="instance" />
    </xf:model>
  </head>
  <body>
    <h1>XForms Enabled Test</h1>
    <xf:submit submission="loadABC">
      <xf:label>Test ABC</xf:label>
    </xf:submit>
    <xf:submit submission="loadError">
      <xf:label>Test Error</xf:label>
    </xf:submit>

    <!-- Normal case, pre-submit and post-submit -->
    <xf:group ref="/data">
      <xf:input ref="a">
        <xf:label>a</xf:label>
        <xf:action ev:event="xforms-enabled">
          <xf:message level="modal">Success</xf:message>
        </xf:action>
      </xf:input>
      <xf:input ref="b">
        <xf:label>b</xf:label>
      </xf:input>
    </xf:group>

    <!-- Error case, post-submit -->
    <xf:group ref="/error">
      <xf:output ref="message">
        <xf:label>Error Message:</xf:label>
      </xf:output>
      <xf:action ev:event="xforms-enabled">
        <xf:message level="modal">Error</xf:message>
      </xf:action>
    </xf:group>
  </body>
</html>

abcdata.xml:
<?xml version="1.0"?>
<data xmlns="">
  <a>1</a>
  <b>2</b>
  <c/>
</data>

error.xml:
<?xml version="1.0"?>
<error xmlns="">
  <message>Simulated Error</message>
</error>

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Mark Birbeck
Sent: Tuesday, April 11, 2006 8:48 AM
To: www-forms@w3.org
Subject: RE: Submission and protocol 'errors' [was RE: Cancel a
submission in progress]


Hi Allan,

> Well, I think we agree on that we need to expose more of the 
> submission process to the form author. I have not thought too much 
> about it though, so I do not currently have any pros or cons for your 
> proposals or a solution either. I guess, what I fear is, that the form

> author ends up replacing his instance data with an error document.
> This is why I want a "distinct path" (I'm searching for a better 
> word...).

That's fair enough--John is also of the same opinion :) which is why I
also described the more event-based approach in the last mail, because I
could the tide was against me!

I actually don't mind either way on this; the author having to move the
data from one instance to another is not dissimilar to how XHR works,
but the author getting an opportunity to influence the movement of the
data as events are fired is also very nice.

And since I'm already outvoted 2-1 at the moment, and no-one seems to be
rushing to support the more explicit approach, we might as well take a
look at what we'd need to have in place to support the event-based
approach...

We at least would need to have a status property on the Event object
that's received in a new event called something like
'xforms-submit-data-received'.
The status value could use the HTTP codes, but it would be abstract--a
request for a database object that doesn't exist, or a local file that
has been deleted should also give a status of 404.

This allows the author to check for errors that they are happy to
process:

  <xf:action
   ev:observer="sub-get-contact"
   ev:event="xforms-submit-data-received"
  >
    <xf:action if="(number(event()/status) = 404">
      ...
    </xf:action>
  </xf:action>

An error property might also be useful; it would indicate that there is
an error, and the form author would need to clear the flag if they want
to prevent an xforms-submit-error from being dispatched at the end of
processing, and the data to be placed in the instance as normal (if
there is
any):

  <xf:action if="(number(event()/status) = 404">
    <xf:setvalue ref="event()/error" value="false()" />
  </xf:action>

They could also *set* the flag--so if Google returns HTTP 200 as you
said, but there are no results, the author could set the error property
and get an 'xforms-submit-error' at the end of processing. They would
need access to the returned data, which I'm not quite sure how to get
from the Event object, since you couldn't use a property directly in the
XPath, so for now let's make it a function:

  <xf:action if="number(event()/response()/@numresults) = 0>
    <xf:setvalue ref="event()/error" value="true()" />
  </xf:action>

As you can see, going this way means leaving the currently defined
processing intact--i.e., if there is an error then no data is copied.
This means that the author in the Google example I just gave has
effectively 'protected' the previous search results by setting the error
flag to true.

So to sum up, we need:

  * a new event, called something like xforms-submit-data-received;

  * a SubmitEvent object with at least three properties on it:

    * status, which is a number, and based on HTTP error codes;

    * error, which is a boolean, and indicates if there is an error
      or not;

    * response, which is the data actually received (a temporary
      instance, perhaps?).

(When accessed via the event() function the last one might be tricky,
but I'm sure we can solve it.)

I think this gives the author quite a lot of control over what
constitutes an error. Any further comments?

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Wednesday, 12 April 2006 00:21:14 UTC