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

51–60 of 103 posts

Re: W3C HTML JSON form submission

#51

Post by ajanuary »

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…

I don't think multiple fields with the same name is designed to be a normal mode of operation. If you actually want an array, use the [] suffix.

But if you have a bug which produces a form with multiple fields with the same name, what should it do? I can think of two strategies: last one wins and the proposal.

Both are probably going to lead to things going wrong in the backend. At least with the proposal you:

A) can detect it with boilerplate that looks for arrays where you expect primitives.

B) figure out what the original data was if you need to try and manually repair it.

I'm sure we'll see lots of bad tutorials suggesting you just use the same field name to make an array though :(

Re: W3C HTML JSON form submission

#52

Post by AlainCouthures »

gsnedders wrote: post #18
matthewmacleod wrote: post #4

Earlier quoted context omitted.

Isn't that kind of like saying "They're still working on HTML after 23 years"? Technically you're right, but version 1.1 of XForms was completed and published over 5 years ago. That said, XForms is dead AFAIK, and that's not a bad thing.

Work on XForms 2.0 is ongoing! Odds of it ever getting implemented in a browser are slim, however.

My XForms implementation (XSLTForms) works in a browser using XSLT and Javascript. The next version will even just require Javascript!

Re: W3C HTML JSON form submission

#53

Post by hayksaakian »

IgorPartola wrote: post #44
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…

PHP handles this by having lists like this by requiring you to use an I put name like "bottle-on-a-wall[]". The brackets indicate that it should be a list. I don't hate this convention...

the only problem with the bracket syntax is when it comes to nested things

        
          
        

        // produces
        {
            "wow":  {
                "such": {
                    "deep": [
                        null
                    ,   null
                    ,   null
                    ,   {
                            "much": {
                                "power": {
                                    "!":  "Amaze"
                                }
                            }
                        }
                    ]
                }
            }
        }

Re: W3C HTML JSON form submission

#54

Post by nkuttler »

pielud wrote: post #24
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?

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.

> It lets you comment out a line without having to remove the trailing comma from the previous line

That would only be an advantage above comma at the end on the last line. It really only moves the problem from the last line to the first one. Now you can't comment out the first line without removing a comma...

Re: W3C HTML JSON form submission

#55

Post by byuu »

Patrick_Devine wrote: post #9

Can we just get rid of HTML and replace it with JSON while we're at it?

I don't know if there's a proper name for this ability, but neither JSON nor YAML allow you to embed child tree nodes inside of node values. This ability requires named end tags. Example:

    
This is bold text.

    "p": "This is ... uh ... nevermind."
You could make a compelling argument that you shouldn't do this (separate block level and inline elements into separate encodings), but remember that even the relatively minor HTML->XHTML movement to put a bit of sanity into single-use tags like
->
failed miserably.

Re: W3C HTML JSON form submission

#56

Post by bobbykjack »

pielud wrote: post #24
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?

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

Re: W3C HTML JSON form submission

#58

Post by SixSigma »

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?

Me, it is so much better. The comma is really a particle of the next item, not the previous.

Here's an item there's going to be another one,

Or

Here's an item

, I'm another one

Re: W3C HTML JSON form submission

#59

Post by dnet »

tonyarkles wrote: post #32
treve wrote: post #11

Earlier quoted context omitted.

Yea this makes me wish there was a better way to deal with this. JSON is popular because it's simple, but as a result sucks for a bunch of use-cases.

I'm mobile so don't have a good way to just test this myself... Any idea how good/bad base64+gzip is (ie gzipping the json before submitting it)? If it's within a few percent then this probably isn't a bad solution!

The browser doesn't gzip _requests_ by itself, only the server does so with the _response_ if the user-agent (including browsers) states that it supports such content encoding. Of course you can implement gzip in JavaScript, but if you do that, you can already mangle the request and send the file to the server without Base64 encoding.

Re: W3C HTML JSON form submission

#60

Post by joesb »

hayksaakian wrote: post #53
IgorPartola wrote: post #44

Earlier quoted context omitted.

PHP handles this by having lists like this by requiring you to use an I put name like "bottle-on-a-wall[]". The brackets indicate that it should be a list. I don't hate this convention...

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.
Post reply on HN