Re: Submitting forms as JSON

my quick take on those questions:

ISSUE 1: JSON root types
every form field has a name and since quite ever. I've never seen <input
name="[]"/> so that the server will receive a list instead of an object so
I don't see why we would go in any other direction. Object is good

ISSUE 2: Path syntax
if that works out of the box in Rails and needs few adjustments in PHP
and/or Java I would say it's already good.
It looks also very "natural" and JSON friendly so I think path as described
is OK

ISSUE 3: Base64
FormData accepts blobs, which is the only thing that would make it more
suitable for files.
This is true only if there won't be the possibility to send
gzipped/deflated data from the client though, as it's demonstrated base64
won't blow "that much" compared with binary and it also will play very well
with big forms and repeated properties.
Latter is true in any case for every big form we know or use already but
here, going base64, I'd like to see such possibility implemented!

ISSUE 4: Is append needed?
append is very used in PHP land and I think are quite handy but I also
remember these are not widely adopted.
I'd chose them if common adoption is higher than non adoption (like a
passive vote from the web community)

ISSUE 5: Boolean radio/checkbox
Usually radio and checkboxes are sent only if checked so that server-side
checks the presence, not its value, right? not an issue, IMO

ISSUE 6: Ignore charsets
if charset can solve anything it should be probably supported with an UTF-8
as default


On Tue, Feb 25, 2014 at 11:19 AM, Brian Kardell <bkardell@gmail.com> wrote:

>
>
>
> On Tue, Feb 25, 2014 at 11:02 AM, Robin Berjon <robin@w3.org> wrote:
>
>> Hi,
>>
>> I put together a small spec to enable having HTML form data submitted
>> directly as JSON, with structure. I'd be curious to hear your feedback:
>>
>>     http://darobin.github.io/formic/specs/json/
>>
>> Thanks!
>>
>> --
>> Robin Berjon - http://berjon.com/ - @robinberjon
>>
>>
>
> Robin,
>
> Some thoughts all over the place...
>
> Would this also modify the FormData serialization in XMLHttpRequest[1].
>  That would be awesomely more useful to me.  It would also be wickedly
> handy if there were a way to get at it (ie, some DOM method), probably more
> useful than even the other two since it would let me polyfill the other two
> with 1 underlying implementation that explains it.   <form>.toObjectModel()
> or something which provides a single canonical non-DOM object
> representation of the form which could be serialized and deserialized could
> be used to explain how enctype="application/json" and corresponding
> FormData in ajax would work too.  Of course, this begs the question of
> whether there is a corresponding <form>.fromObjectModel() which could
> populate the form given some data (kinda awesome), and whether both of
> those are maybe just natively handleable custom serializations ala
> JSON.stringify(form) and JSON.parse(form)..
>
>
> http://www.w3.org/TR/XMLHttpRequest2/#interface-formdata
>
>
>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
>