[whatwg] Fwd: Re: Form Serialization Idea

On 9/26/07, Asbj?rn Ulsberg <list at asbjorn.ulsberg.no> wrote:
> On Tue, 25 Sep 2007 12:32:05 +0200, Asbj?rn Ulsberg <asbjorn at ulsberg.no>
> wrote:
> > Can't overload in JS.
> Not in the normal sense, but I think you understand what I'm looking for.
> > There isn't any toString on HTMLFormElement.
> So it can't be introduced? Aren't we introducing new features here? How is
> toJSONString() easier to introduce than toString()?
> > Having a parameterized toString wouldn't really make sense, either.
> Why not? It's clearly the most elegant solution to me.
> > You can't override toString because it isn't guaranteed to be
> > available on host objects.
> Neither is toJSONString().
Well, toJSONString probably will be. It will complicate javascript
even more. If you ask me, I say that this should not go in the
language. I'd rather have a JSON object for that. I'm in the minority.

> > toString is useful for examining an element's state.
> Isn't that exactly what you're doing with toJSONString()? You get a string
> representation of the current state of the object and child objects.
Well, really toString is useful for things like
return super.toString()
 + "\n=====================\n"
 + name: " + this.name + "\nthis.name);

But JS uses it as if it were to be relied on for formattting. And
we've got the Number.prototype.toString( radix ), so there you go
w/param'd toString.

> > Host objects are not quite javascript objects, so it wouldn't be an
> > override of Object.prototype. AFAIK, Host objects are not req'd to
> > support Object.prototype.
> True, they are a bit quirky, especially in JScript. However, I don't see
> the big difference in implementing toString() versus toJSONString().

> > How about using a mime type for the JSON and put that on the form? I
> > think someone mentioned this over at the HTML 5 WG list.
> Yes, that could be possible. It's a bit awkward to have to set a property
> on the form ('enctype') before retreiving the form's current state
> represented in that MIME type, though. I'd rather see this:
>    var s = document.getElementById('myform').toString('application/json');
> than:
>    var f = document.getElementById('myform');
>    f.setAttribute('enctype', 'application/json');
>    var s = f.toString();
> To be clear, since I haven't written it so far; my point isn't that the
> method's name is 'toString' but that it's extensible beyond the scope of
> retreiving a JSON string. We should be able to retreive the state in any
> MIME type available, without having to implement one method per MIME type:
>    HTMLFormElement.toJSONString();
>    HTMLFormElement.toMultipartFormDataString();
>    HTMLFormElement.toXMLString();
> etc.
> > This might be more suitable to have the JSON separated from the data
> > serialization.
> If I understand you correctly; yes.
We agree on that. I'm going to add that to the page. I'd actually like
it to be a wiki page so you could just edit it yourself, but it's not
so you can't...

> > A serialized Data Set, just like what you see when you submit a form
> > -- the query string in a get or the post body in a POST.
> But in the representation you want, right? How often do you want
> 'multipart/form-data' in your JavaScript application?
I'd like this functionality. It would be super useful.

I'd also like to have the getData functionality be generic. I really
like your suggestion. I would rather have a unique name, than toString

Thank you.

> --
> Asbj?rn Ulsberg           -=|=-        asbjorn at ulsberg.no
> ?He's a loathsome offensive brute, yet I can't look away?

Programming is a collaborative art.

Received on Tuesday, 2 October 2007 23:54:13 UTC