[whatwg] Fwd: Re: Form Serialization Idea

[Garrett Smith]

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

Thank you.

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


-- 
Programming is a collaborative art.