Re: A new submit method for implementing replace="all" with Javascript ?

Thank you very much for these explanations. I didn't get the error mechanism problematic.

I surely think that it is important to let the browser handle navigation and history, especially when mixing forms and static pages for Web sites, because navigation buttons are effectively there...

Error checking is, of course, also very important and I just can imagine that, if replace="all" is performed with XMLHttprequest, when there is no error, a page with "windows.location.href=..." (eventually containing a context parameter) has always to be sent by the server to effectively change the current page. It's much more complicated for the server.

Even though errors should be firstly detected before replace="all" submission, new errors can always appear just after submission, when the server checks again and tries to lock data before updating... So, disabling the error mechanism could force the server to resend the same page with the corresponding instance : I think it should not happen too often.

That's why I think that your idea of adding a new attribute is a good one, something indicating that this submission is definitive.

HTML and Javascript are not perfect for implementing XForms... but it's the only way for browsers without plug-in !

Alain COUTHURES
<agenceXML>
http://www.agencexml.com/xsltforms/
Bordeaux, France

Paul Butcher a écrit :
> If I understand correctly, the post body behaviour you describe is
> already the mandated behaviour for the submission method
> "multipart-post", i.e. that the XML, rather than being the body of the
> postdata, or being serialised into name-value pairs, is one part of a
> form-data-post.  The description could also be interpreted as a
> form-urlencoded-post
> http://www.w3.org/TR/xforms11/#serialize-urlencode, but with a single
> instancedata parameter, rather than having the instance broken into
> name-value pairs.
>
> Either way, the issue you wish to resolve by this is not related to
> the serialisation of the instance data for sending, but in the way the
> response is handled.
>
> I imagine that you are intending to implement this by simply invoking
> the browser's HTML form submit.  Thereby allowing the browser to
> handle its own navigation and history changes.  Unfortunately, even if
> a new submission method were added to signify this, it would still not
> be conformant for other reasons.
>
> A significant difference between HTML form submission and XForms
> submission, is that XForms submissions give the opportunity to inspect
> the response, prior to writing it into the instance data or outputting
> to screen.  A submission that returns an error response should not
> replace any data (http://www.w3.org/TR/xforms11/#submit-evt-submit)
> (last bullet before the example)
>
> The facility you desire appears to be that one can specify a
> submission with replace="all", that simply executes and exposes the
> raw data to the user regardless of any errors that may occur.  This
> would require a change to the nature of submission handling, and
> possibly a new submission attribute to switch such behaviour on or
> off.
>

Received on Wednesday, 17 December 2008 14:45:53 UTC