W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2007

[whatwg] Form Serialization

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Thu, 9 Aug 2007 22:21:01 -0400
Message-ID: <6b9c91b20708091921y1148c3b7r7c814e35cfe59c29@mail.gmail.com>
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.

1. *Potential* ease of working around form handling bugs when you
really need to.
Although if the form handling is broken, the methods might be too, but
it still might be easier to get the broken data set and fix it instead
of generating the data set yourself. At least with getDataString, it
would show you what's going to be submitted.

I could imagine an onsubmit, e.preventDefault() and
e.target.getDataString() being useful.

2. Form handling extensions.

If you want to support the foobambang: protocol, you could use the
object  and its array values to generate a foobambang:-conforming URI
and open it (using the default handler for foobambang URIs).

-- 
Michael
Received on Thursday, 9 August 2007 19:21:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:36 UTC