Re: Submission errors and @replace="instance" [was RE: AJAX vs. Xforms]

Mark Birbeck wrote:

> Hi Aaron,
> 
> I hope all is well.
> 

Things are going great.  Thanks for asking.

> 
>>I understand what you are saying, but I don't see it actually happening. 
>>If I do a submission to http://xformstest.org/cgi-bin/echo.shaka, then 
>>with Novell's IE plugin and formsPlayer, I don't get the 
>>xforms-submit-error and I do see the normal HTML 404 error page.  Is 
>>this a bug?  I do see the value of showing the user the error message 
>>from the server, but I also see the value of not replacing anything in 
>>the document as per spec.  Here is the testcase that I tried:
>>
>>[snip]
> 
> 
> Don't forget that the default for xf:submission is @replace="all", which
> wipes out your document. We're talking about @replace="instance", and yes,
> you are right there is a good case for saying don't do that replace if there
> is an error.

Looks like the document shouldn't be replaced according to the spec: 
"For an error response nothing in the document is replaced, and submit 
processing concludes after dispatching xforms-submit-error."

But I do like the idea of displaying the error that the server served 
back when 'replace="all"' is the case.  Any way we can get that line 
changed in the spec to allow for this?

> 
> Personally, I don't really mind which way round it goes since I can see a
> 'logical' explanation for both ways. The method I was suggesting the other
> day would require the author to move the successful instance to one place,
> and a failed instance to another, since the actual instance would always be
> replaced if there was an XML 'body' returned.
> 
> However, if as you say, we say that the instance is not replaced unless the
> submission is marked as a success, then one solution to my problem would be
> to add another attribute to xf:submission to indicate the instance that any
> 'error' XML should go to. Or we could use the event() XPath function
> (defined in XForms 1.1) to get access to the DOM returned.
> 
> So there are lots of ways to go--the main thing from my side is simply to
> establish that there is a need for that returned data.
> 

DEFINITELY a need for the data.  I really don't like the form author 
having to set aside instance in anticipation of all possible errors that 
may happen.  I do really like having the error hang around, though, to 
be checked later, which event() doesn't give you.  Maybe we should think 
about allowing lazy authoring of the error?  Possibly like this:

<xf:model id="myModel">
   ...
   <xf:submission id="mySubmission".....  lastError="myError"/>
</xf:model>

and if mySubmission gets a xforms-submit-error, than the stream contents 
that come back from the server get inserted in a lazy-authored instance 
element with the id of myError under the model that contains the 
xf:submission.  If data already exists there, then it is wiped in favor 
of the most recent error data.  So now myModel contains something that 
looks like this:

<xf:instance id="myError>
   <instanceData>
     ...returned data...
   </instanceData>
</xf:instance>

We'd probably have to have some kind of fatal error on load if any 
xf:submission has an @error value that wouldn't be unique in the document.

Have a great evening,
--Aaron

Received on Thursday, 27 October 2005 21:09:26 UTC