W3C home > Mailing lists > Public > www-forms@w3.org > December 2008

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

From: Paul Butcher <paul.butcher@webbackplane.com>
Date: Wed, 17 Dec 2008 13:44:32 +0000
Message-ID: <5d62ecc70812170544l66427f00v5daa85662e86b5ea@mail.gmail.com>
To: "COUTHURES Alain" <alain.couthures@agencexml.com>
Cc: www-forms@w3.org

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
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

On Sat, Nov 22, 2008 at 5:48 PM, COUTHURES Alain
<alain.couthures@agencexml.com> wrote:
> Hello,
> Reading XForms 1.0 Recommendation and XForms 1.1 Candidate Recommendation, I
> think it might be useful to add another way of serialization as
> application/x-www-form-urlencoded with just one input field containing the
> serialized XML.
> The problem I'm encountering is about implementing ' replace="all" ' in
> Javascript. I am re-engineering AJAXForms
> (http://www.agencexml.com/xsltforms) and, after replacing Java parts with an
> XSL transformation so it can be client-side, I have to modify Javascripts
> submit parts. AJAXForms, which was not designed for XHTML, is using
> XMLHttpRequest and "document.write()".
> First, I replaced "document.write(req.responseText)" with
> "document.documentElement.parentNode.replaceChild(req.responseXML.documentElement,document.documentElement)"
> for XHTML response and "document.documentElement.innerHTML =
> req.responseText" for non XHTML response (I should actually process all
> childNodes of document.documentElement.parentNode...) . But, even so, it
> doesn't work perfectly for FF3 (title not updated !) and Opera (display not
> fully cleared !), and the previous URI is, of course, still the current one
> : reload and backward buttons do not act as if it were a new page...
> I would prefer browsers to completely replace the page the way they usually
> do for HTML form submit or for HTML anchor : XSL transformation if
> mentioned, CSS import, Javascript execution,... It would prevent memory leak
> and every kind of problems resulting from a unique page been modified, and
> modified, and modified...
> So, instead of XMLHttpRequest, HTML form submit would do the trick but, at
> least, one input field is required. Just one input field, named "postdata"
> for example, would be good to contain the serialized XML. This new submit
> method could be named "xml-urlencoded-post".
> I would appreciate to have your points of view.
> Thank you in advance.
> <agenceXML>
> http://www.agencexml.com
> Bordeaux, France


Received on Wednesday, 17 December 2008 13:45:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:58 UTC