- From: Asbjørn Ulsberg <list@asbjorn.ulsberg.no>
- Date: Wed, 26 Sep 2007 12:01:40 +0200
- To: "Garrett Smith" <dhtmlkitchen@gmail.com>
- Cc: "Web API WG (public)" <public-webapi@w3.org>
On Tue, 25 Sep 2007 12:32:05 +0200, Asbjørn Ulsberg <asbjorn@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().
> 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.
> 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 could JSON form serialization work with data: on HTML 5? Is it
> something that could be integrated?
I don't think I understand this question. Are you speaking about 'data:'
URIs?
> 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.
> 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?
--
Asbjørn Ulsberg -=|=- asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»
Received on Wednesday, 26 September 2007 10:01:16 UTC