W3C home > Mailing lists > Public > public-webapi@w3.org > September 2007

Re: Fwd: Re: Form Serialization Idea

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>
Message-ID: <op.ty8942pekc4es2@quark>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:58 GMT