- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Thu, 27 Oct 2005 21:07:28 +0100
- To: "'Aaron Reed'" <aaronr@us.ibm.com>
- Cc: <www-forms@w3.org>
Hi Aaron, I hope all is well. > 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. 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. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Thursday, 27 October 2005 20:07:50 UTC