- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 2 Oct 2007 23:54:13 -0700
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.
Received on Tuesday, 2 October 2007 23:54:13 UTC