[whatwg] Fwd: Re: Form Serialization Idea
dhtmlkitchen at gmail.com
Tue Oct 2 23:54:13 PDT 2007
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>
> > 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().
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
+ 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
> > 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');
> 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:
> > 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
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
> Asbjørn Ulsberg -=|=- asbjorn at ulsberg.no
> «He's a loathsome offensive brute, yet I can't look away»
Programming is a collaborative art.
More information about the whatwg