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 Tuesday, 11 April 2006 15:49:19 UTC