Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

W3C HTML JSON form submission

w3.org

Post reply on HN
Print view View original

61–70 of 103 posts

Re: W3C HTML JSON form submission

#61

Post by tomchristie »

rspeer wrote: post #42

Let me say first of all that I'm glad they're working on standardizing this. When making REST APIs, I find HTML form scaffolds incredibly useful, but it means that you probably have to accept both JSON (because JSON is reasonable) and occasional form-encoding (because forms), leading to subtle incompatibilities. Or you have to disregard HTML and turn your forms into JavaScript things that submit JSON. Either way, the…

Think that's fair point, yup. Very easy to do unintentionally, and it's non-intuitive that it'll suddenly change the return type.

It's not clear if this style is really necessary. Why not just use the indexed syntax in this case?

I guess it may be the authors intention to mirror form encoded submissions, that would send all of these values to the server.

I'd suggest raising the point on the issue tracker so that it at least gets sufficient design discussion.

https://github.com/darobin/formic/issues

Re: W3C HTML JSON form submission

#62

Post by tomchristie »

Seems pretty decent. Also neat that the nesting style could be repurposed to support nested structures in regular form-encoded HTML forms.

Main limitation on actually being able to use this is that `GET` and `POST` continue to be the only supported methods in browser form submissions right now, so eg. you wouldn't be able to make JSON `PUT` requests with this style anytime soon.

Might be that adoption of this would swing the consensus on supporting other HTTP methods in HTML forms.

Re: W3C HTML JSON form submission

#63

Post by billpg »

A new standard for referencing a point in a JSON object? I wonder if they considered RFC 6901 and rejected it.

I personally prefer this new square bracket notation, but being a standard already gets more points.

Re: W3C HTML JSON form submission

#64

Post by jdp »

The latest release of my jarg[0] utility supports the HTML JSON form syntax. Writing out JSON at the command line is tedious, this makes it a little nicer. The examples from the draft are compatible with jarg:

    $ jarg wow[such][deep][3][much][power][!]=Amaze
    {"wow": {"such": {"deep": [null, null, null, {"much": {"power": {"!": "Amaze"}}}]}}}
[0]: http://jdp.github.io/jarg/

Re: W3C HTML JSON form submission

#65

Post by byuu »

joesb wrote: post #60
hayksaakian wrote: post #53

Earlier quoted context omitted.

the only problem with the bracket syntax is when it comes to nested things // produces { "wow": { "such": { "deep": [ null , null , null , { "much": { "power": { "!": "Amaze" } } } ] } } }

What's the problem with that? If it's deeply nested, then it's deeply nested, no matter what.

It's pedantic, but it's a tad clunky now: I'd use something like "wow/such/deep[3]/much/power/!" to differentiate child nodes from array indexes, and also strongly advise against a node named "!" on principle. Of course then you'd say "but I want '/' in my node name!", and then you get to bikeshed an escape sequence, but you'd need that anyway for a node name with '[' or ']' in it.

However, what they've done is workable if all the browser vendors implement it.

Re: W3C HTML JSON form submission

#66

Post by Joeri »

bobbykjack wrote: post #56
pielud wrote: post #24

Earlier quoted context omitted.

It lets you comment out a line without having to remove the trailing comma from the previous line. That'd be useful if JSON had comments. I've seen people do this in the SELECT portion of SQL queries too. Personally, I hate this.

If IE didn't barf on a trailing comma after the last value, we wouldn't have this problem. That's probably the biggest source of all my IE JavaScript bugs. To be fair, I'm not actually sure what the spec says, but the spec might be wrong :-)

IE9 and above should handle it fine, so it's just a matter of time before this problem goes away. In the meantime there are two things you can do: use an editor which highlights this as an error (e.g. Webstorm), or add a pre-commit hook on your code repository which disallows committing code that doesn't pass jslint checks. We use both practices on a 200 kline js codebase, and it has essentially gotten rid of javascript errors at the customer due to bad syntax (as well as those tricky = / == / === issues).

Re: W3C HTML JSON form submission

#68

Post by [deleted] »

billpg wrote: post #63

A new standard for referencing a point in a JSON object? I wonder if they considered RFC 6901 and rejected it. I personally prefer this new square bracket notation, but being a standard already gets more points.

[deleted]

Re: W3C HTML JSON form submission

#69

Post by icebraining »

stu_k wrote: post #8

Submitting files with this form encoding is of course going to have the base64 overhead, but otherwise this looks great!

In fact, HTML already has a solution for that in the form of multipart/form-data.

Instead of encoding the files directly inside JSON, you could add them as extra parts of the MIME message, and just have a reference in the JSON value (as in email, which uses a "cid:" URI to inline images as such, as described in RFC2392).

You'd still need special support on the server, though.

Re: W3C HTML JSON form submission

#70

Post by Xophmeister »

hughes wrote: post #21

{ "name": "Bender" , "hind": "Bitable" , "shiny": true } Who puts commas at the start of a continuing line? What good could that possibly do?

The comma first pattern is pretty common. I've seen it used in JavaScript (as well as JSON), SQL and Haskell; I'm sure there are others.

Some encourage this so you can comment out a line without having to add/remove commas. However, this isn't the case if you want to comment out the first line; so in effect, it just moves the problem from the bottom to the top of the list. Other proponents say it's easier to spot typos (i.e., missing commas). For example:

    var something = {
      foo: 'bar',
      abc: '123'
      quux: null,
      xyz:  456
    };
vs:

    var something = {
      foo: 'bar'
    , abc: '123'
      quux: null
    , xyz:  456
    };
In the second one, it's clearer that there's a comma missing.

Personally, I think it's ugly and, while I'm sure I've erroneously omitted commas before, they're caught by the parser. No example comes immediately to mind where missing a comma can be interpreted as something other than a parse error.

Post reply on HN