[whatwg] Form Serialization`

[Garrett Smith]

> > On 8/8/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> > Most libraries now are providing a way to serialize a form.
> >
> > It would be useful to have:
> >
> >  HTMLFormElement.prototype.toJSONString
> >  HTMLFormElement.prototype.getDataSetString
> >
> > HTMLFormElement.prototype.toJSONString would return an object literal
> > that contains the enabled (not readonly) form element names as keys
> > and an array for each key's value.
> >
> > aForm.getDataString() would return a serialized data set
> > representation of the form's successful controls.
>
> Yes, these would be useful for 2 reasons that I can think of.
>
<snip>
I disagree.

Why would anyone want to serialize a FORM?

Here's why:

Most "AJAX" libraries already provide functionality for serializing a
FORM (even if indirectly, by associating a FORM with an "AJAX"
request).

I hope this cumbersome, bloated approach will become obsolete in the
near future.

FORMs are sometimes used for XMLHttpRequest.

Why should forms be used for XHR?

Using a FORM for an XHR is a more explicit than hard coding the url
and params in the javascript. It's a good practice. It avoids the
nastiness of having the URL embedded in the script and shows just what
arguments (parameters) the method will take by exposing the remote
method's signature to the client side developer.

What is the problem?

Form serialization by hand is not simple. That is why all the "ajax"
libs do it for you. So you get stuck using Dojo, or one of the other
libraries to do it for you. But then you have all the associated crud
with that library.

Serializing a FORM by hand should not be necessary -- the browser
ALREADY does this for us automatically. Let's let the browser do this
for us by providing the method. (low cost, high impact).

We should be able to get the FORM data and submit it with XHR -- all
without having to peel through the form and concatenate strings.

Garrett

> --
> Michael
>