- 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