Re: Submitting forms as JSON

I think this list of issues is actually good evidence that we should build
from the ground up here and let the library ecosystem drive this for a bit
before getting the feature into the platform.

I'd expect the entire process to take no longer than trying to standardize
it a priori, and be less error prone.

Yehuda Katz
(ph) 718.877.1325


On Tue, Feb 25, 2014 at 11:40 AM, Andrea Giammarchi <
andrea.giammarchi@gmail.com> wrote:

> 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
>>
>
>