Am 10.10.2015 um 21:46 schrieb Marc Schütz:

Am Fri, 09 Oct 2015 19:21:40 GMT
schrieb "Sönke Ludwig" sludwig@rejectedsoftware.com:

On Fri, 09 Oct 2015 07:27:00 GMT, o3o wrote:

(...) 

void postSettings(bool[] x) {

when I click submit the server freezes.

Thank you...

That's indeed a bug. The problem is that the two definitions for
handling "array" and "boolean" parameters don't fit together. The
rule for dynamic arrays is to continue to gather values until a
certain index doesn't exist anymore in the submitted form. However,
checkbox/boolean values are transmitted with "true === field is
submitted" and "false === field is not submitted", so it's not
possible to determine the end of the array unambiguously.

The check_box helper Rails inserts a hidden field with the same name
as the check box and the value "0" before the actual check box. Because
form fields are guaranteed to be submitted in order, an unchecked
checkbox submits as key=0 and a checked one as key=0&key=1, the "1"
overwriting the "0".

Hm... that's a possibility, but I can't say that I'm particularly
thrilled, especially without a form generator that assists in getting
this right. But at least it's a solution...

Emitting a hidden "x.length" field that contains the count would be
another option.

The question is if there is any meaningful way to express bool[] on
the form level at all. If not, there should be a compile time error.
An alternative is to add support for static arrays (bool[2]), which
I did now with
92f4ae0.

Another possibility is to enable an alternative mode for dynamic
array parameters, where the same field name can be used multiple
times. The example could then look similar to this: 

@multiField!"x"
void postSettings(string[] x)
{
// x is something like ["foo", "baz"]
}

form(action="settings", method="POST")
input(type="checkbox", name="x", value="foo")
input(type="checkbox", name="x", value="bar")
input(type="checkbox", name="x", value="baz")
button(type="submit") OK

I find the current scheme rather bizarre. Why wasn't the "normal"
convention that basically everyone else uses adapted? That is: 

key=value			scalar
key[]=value1&key[]=value2	normal array
key[a]=value1&key[b]=value2	associative array

It's just historically based. The ancestor of the current module was
registerFormInterface, which was made by a contributor who disappeared
after a while. When I started to create the successor module, basic
compatibility was a priority.

I had already started to implement the above scheme last year in a
branch, but was never able to merge the changes due to other changes
getting in the way (I've deleted the branch now and it needs to be
redone). My proposal is to implement some transitional steps:

  1. Add a WebInterfaceSettings.fieldNamingScheme enum that defaults to
    FieldNamingScheme.legacyDefault.
  2. Emit a deprecation warning if the default isn't explicitly set to
    either .dStyle or .underscore
  3. Switch the default to .dStyle

(enum names subject to change...)

It's not seamless, but at least there won't be any silent breakage.