Re: [whatwg] Adding FormData support to form
On Sat, 27 Feb 2010 01:12:21 +0100, Anne van Kesteren ann...@opera.com wrote: On Fri, 26 Feb 2010 23:28:12 +0100, Maciej Stachowiak m...@apple.com wrote: On Feb 26, 2010, at 11:37 AM, Michael Nordman wrote: Sure, but a better name could help a bit. For example, this produces a 'shared' object: document.getElementById(foo) while this creates a new one: myFormElement.getFormData() It might be ok, but it is a bit inconsistent. Why not: formData = new FormData(); formData = new FormData(myFormElement); ah... +1 the ctor Indeed, constructor syntax makes it very clear that you are getting a new object. I like. I could add this to XMLHttpRequest Level 2. Just to close this thread in my inbox. This thread moved over to public-webapps where I finally followed up with something tangible: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0416.html -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Adding FormData support to form
On Fri, Feb 19, 2010 at 8:52 AM, Dmitry Titov dim...@google.com wrote: On Thu, Feb 18, 2010 at 8:45 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 17, 2010, at 3:15 PM, Jonas Sicking wrote: The reason this is a function rather than a read-only attribute is to allow the return FormData to be further modified. I.e. the following should be allowed: fd = myFormElement.getFormData(); fd.append(foo, bar); xhr.send(fd); If it was a property I would be worried about people expecting the following to work: myFormElement.formData.append(foo, bar); xhr.send(myFormElement.formData); However I don't think there is a good way to make the above work. Thus my suggestion to use a function instead. I'm writing a prototype implementation over in [2] People could imagine that this should work: myFormElement.getFormData().append(foo, bar); xhr.send(myFormElement.getFormData()); In either case, it seems that once they see it doesn't work, they will no longer expect it to work. Sure, but a better name could help a bit. For example, this produces a 'shared' object: document.getElementById(foo) while this creates a new one: myFormElement.getFormData() It might be ok, but it is a bit inconsistent. Why not: formData = new FormData(); formData = new FormData(myFormElement); ah... +1 the ctor Regards, Maciej
Re: [whatwg] Adding FormData support to form
On Feb 26, 2010, at 11:37 AM, Michael Nordman wrote: Sure, but a better name could help a bit. For example, this produces a 'shared' object: document.getElementById(foo) while this creates a new one: myFormElement.getFormData() It might be ok, but it is a bit inconsistent. Why not: formData = new FormData(); formData = new FormData(myFormElement); ah... +1 the ctor Indeed, constructor syntax makes it very clear that you are getting a new object. I like. - Maciej
Re: [whatwg] Adding FormData support to form
On Fri, 26 Feb 2010 23:28:12 +0100, Maciej Stachowiak m...@apple.com wrote: On Feb 26, 2010, at 11:37 AM, Michael Nordman wrote: Sure, but a better name could help a bit. For example, this produces a 'shared' object: document.getElementById(foo) while this creates a new one: myFormElement.getFormData() It might be ok, but it is a bit inconsistent. Why not: formData = new FormData(); formData = new FormData(myFormElement); ah... +1 the ctor Indeed, constructor syntax makes it very clear that you are getting a new object. I like. I could add this to XMLHttpRequest Level 2. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Adding FormData support to form
On Thu, Feb 18, 2010 at 8:45 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 17, 2010, at 3:15 PM, Jonas Sicking wrote: The reason this is a function rather than a read-only attribute is to allow the return FormData to be further modified. I.e. the following should be allowed: fd = myFormElement.getFormData(); fd.append(foo, bar); xhr.send(fd); If it was a property I would be worried about people expecting the following to work: myFormElement.formData.append(foo, bar); xhr.send(myFormElement.formData); However I don't think there is a good way to make the above work. Thus my suggestion to use a function instead. I'm writing a prototype implementation over in [2] People could imagine that this should work: myFormElement.getFormData().append(foo, bar); xhr.send(myFormElement.getFormData()); In either case, it seems that once they see it doesn't work, they will no longer expect it to work. Sure, but a better name could help a bit. For example, this produces a 'shared' object: document.getElementById(foo) while this creates a new one: myFormElement.getFormData() It might be ok, but it is a bit inconsistent. Why not: formData = new FormData(); formData = new FormData(myFormElement); Regards, Maciej
Re: [whatwg] Adding FormData support to form
On Thu, 18 Feb 2010 23:06:12 +0100, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Feb 17, 2010 at 11:30 PM, Anne van Kesteren ann...@opera.com
wrote:
On Thu, 18 Feb 2010 00:15:25 +0100, Jonas Sicking jo...@sicking.cc
wrote:
So I suggest we add a method like
interface HTMLFormElement : HTMLElement {
...
FormData getFormData();
...
};
Should we name it toFormData() instead for consistency with canvas?
Or is
canvas inconsistent with something else?
There are much more functions that are named getX than toX in the
DOM. Such as getElementById, getElementsByTagName,
getBoundingClientRect.
Sure, but this seems more analogous to toDataURL() than to
getElementById(). YMMV.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Adding FormData support to form
On Thu, 18 Feb 2010, Anne van Kesteren wrote:
On Thu, 18 Feb 2010 23:06:12 +0100, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Feb 17, 2010 at 11:30 PM, Anne van Kesteren ann...@opera.com
wrote:
On Thu, 18 Feb 2010 00:15:25 +0100, Jonas Sicking jo...@sicking.cc
wrote:
So I suggest we add a method like
interface HTMLFormElement : HTMLElement {
...
FormData getFormData();
...
};
Should we name it toFormData() instead for consistency with canvas? Or
is
canvas inconsistent with something else?
There are much more functions that are named getX than toX in the
DOM. Such as getElementById, getElementsByTagName,
getBoundingClientRect.
Sure, but this seems more analogous to toDataURL() than to
getElementById(). YMMV.
toDataURL() was named that way for consistency with toString(), which
seems a closer analogue here than getElementById() and friends.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding FormData support to form
On Fri, Feb 19, 2010 at 1:52 PM, Ian Hickson i...@hixie.ch wrote: toDataURL() was named that way for consistency with toString(), which seems a closer analogue here than getElementById() and friends. bikeshed But you're not really converting the form element into something equivalent, are you? That's what to methods usually imply, IMHO. Maybe it should be createFormData or extractFormData? /bikeshed Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Adding FormData support to form
On Fri, 19 Feb 2010, Robert O'Callahan wrote: On Fri, Feb 19, 2010 at 1:52 PM, Ian Hickson i...@hixie.ch wrote: toDataURL() was named that way for consistency with toString(), which seems a closer analogue here than getElementById() and friends. But you're not really converting the form element into something equivalent, are you? That's what to methods usually imply, IMHO. Maybe it should be createFormData or extractFormData? create* is generally used for independent factory methods that aren't based on the state of the object they're invoked on. extract* would be a new convention... I think toFormData() here is converting the form to the same extent toDataURL() is converting the canvas. But I'll spec whatever ends up implemented, if it's implemented by the time I get around to responding to this thread properly. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding FormData support to form
On Thu, Feb 18, 2010 at 5:30 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Feb 19, 2010 at 1:52 PM, Ian Hickson i...@hixie.ch wrote: toDataURL() was named that way for consistency with toString(), which seems a closer analogue here than getElementById() and friends. bikeshed But you're not really converting the form element into something equivalent, are you? That's what to methods usually imply, IMHO. Maybe it should be createFormData or extractFormData? /bikeshed This was my reasoning too. I'm not a big fan of 'createFormData' as to me it doesn't sound like it'll also populate the FormData with the current values. Possibly due to the similarity with 'createElement'. 'extractFormData' sounds ok though, though i think 'getFormData' is nicer due to its shorter name. / Jonas
Re: [whatwg] Adding FormData support to form
On Thu, 18 Feb 2010 21:20:38 -0500, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 18, 2010 at 5:30 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Feb 19, 2010 at 1:52 PM, Ian Hickson i...@hixie.ch wrote: toDataURL() was named that way for consistency with toString(), which seems a closer analogue here than getElementById() and friends. bikeshed But you're not really converting the form element into something equivalent, are you? That's what to methods usually imply, IMHO. Maybe it should be createFormData or extractFormData? /bikeshed This was my reasoning too. I'm not a big fan of 'createFormData' as to me it doesn't sound like it'll also populate the FormData with the current values. Possibly due to the similarity with 'createElement'. 'extractFormData' sounds ok though, though i think 'getFormData' is nicer due to its shorter name. A while ago, I mentioned this http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-January/018097.html as getFormData(). I still like that name. -- Michael
Re: [whatwg] Adding FormData support to form
On Feb 18, 2010, at 2:06 PM, Jonas Sicking wrote:
On Wed, Feb 17, 2010 at 11:30 PM, Anne van Kesteren
ann...@opera.com wrote:
On Thu, 18 Feb 2010 00:15:25 +0100, Jonas Sicking
jo...@sicking.cc wrote:
So I suggest we add a method like
interface HTMLFormElement : HTMLElement {
...
FormData getFormData();
...
};
Should we name it toFormData() instead for consistency with
canvas? Or is
canvas inconsistent with something else?
There are much more functions that are named getX than toX in the
DOM. Such as getElementById, getElementsByTagName,
getBoundingClientRect.
I agree. toFoo implies a mere conversion. But getting the FormData is
not just a type conversion.
However, I also think 0-argument getters are a bad pattern in
JavaScript. Why not just use an attribute?
interface HTMLFormElement : HTMLElement {
...
readonly attribute FormData formData;
...
};
Regards,
Maciej
Re: [whatwg] Adding FormData support to form
On Thu, Feb 18, 2010 at 10:28 PM, Maciej Stachowiak m...@apple.com wrote:
However, I also think 0-argument getters are a bad pattern in JavaScript.
Why not just use an attribute?
interface HTMLFormElement : HTMLElement {
...
readonly attribute FormData formData;
...
};
Jonas addressed that in the original email - he (rightfully, I feel)
fears that if it's an attribute, people will assume that it can be
assigned to.
I see absolutely nothing wrong with 0-argument getters, personally.
~TJ
Re: [whatwg] Adding FormData support to form
On Feb 18, 2010, at 8:36 PM, Tab Atkins Jr. wrote:
On Thu, Feb 18, 2010 at 10:28 PM, Maciej Stachowiak m...@apple.com
wrote:
However, I also think 0-argument getters are a bad pattern in
JavaScript.
Why not just use an attribute?
interface HTMLFormElement : HTMLElement {
...
readonly attribute FormData formData;
...
};
Jonas addressed that in the original email - he (rightfully, I feel)
fears that if it's an attribute, people will assume that it can be
assigned to.
There's lots of readonly attributes in the DOM. Are we worried about
people trying to assign to Node.firstChild? NodeList.length?
Event.target? Seems like a concern that is not borne out by experience.
Furthermore, making the attribute writable might even be useful. You
could imagine saving the state of a form in client-side storage and
wanting to restore it later while offline. Sure, you could extract the
control values yourself and make up your own serialization format, but
that seems like a waste when you have sweet tasty FormData.
I see absolutely nothing wrong with 0-argument getters, personally.
I don't see the point, in a language that supports getter attributes.
Why would you want to write form.getFormData() instead of
form.formData? It's just a waste. I say save the parentheses for when
there are either parameters or side effects rather than just getting a
value.
Regards,
Maciej
Re: [whatwg] Adding FormData support to form
On Feb 17, 2010, at 3:15 PM, Jonas Sicking wrote: The reason this is a function rather than a read-only attribute is to allow the return FormData to be further modified. I.e. the following should be allowed: fd = myFormElement.getFormData(); fd.append(foo, bar); xhr.send(fd); If it was a property I would be worried about people expecting the following to work: myFormElement.formData.append(foo, bar); xhr.send(myFormElement.formData); However I don't think there is a good way to make the above work. Thus my suggestion to use a function instead. I'm writing a prototype implementation over in [2] People could imagine that this should work: myFormElement.getFormData().append(foo, bar); xhr.send(myFormElement.getFormData()); In either case, it seems that once they see it doesn't work, they will no longer expect it to work. Regards, Maciej
[whatwg] Adding FormData support to form
The FormData object [1] is a great way to allow multipart/form-data
encoded content to be submitted using XMLHttpRequest. It would be
great if it was possible to get a FormData object representing the
data contained in a form. This in order to allow normal HTML forms
being used, but using XMLHttpRequest to submit the form data in order
to allow AJAX to be used.
So I suggest we add a method like
interface HTMLFormElement : HTMLElement {
...
FormData getFormData();
...
};
The reason this is a function rather than a read-only attribute is to
allow the return FormData to be further modified. I.e. the following
should be allowed:
fd = myFormElement.getFormData();
fd.append(foo, bar);
xhr.send(fd);
If it was a property I would be worried about people expecting the
following to work:
myFormElement.formData.append(foo, bar);
xhr.send(myFormElement.formData);
However I don't think there is a good way to make the above work. Thus
my suggestion to use a function instead. I'm writing a prototype
implementation over in [2]
[1]
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/Overview.html#the-formdata-interface
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=546528
/ Jonas
Re: [whatwg] Adding FormData support to form
On Thu, 18 Feb 2010 00:15:25 +0100, Jonas Sicking jo...@sicking.cc wrote:
So I suggest we add a method like
interface HTMLFormElement : HTMLElement {
...
FormData getFormData();
...
};
Should we name it toFormData() instead for consistency with canvas? Or
is canvas inconsistent with something else?
--
Anne van Kesteren
http://annevankesteren.nl/
