Re: Somewhat incorrect multi-value query parameter processing

Brandon Long wrote:
> Even with your patch, you'd get something like:
> node = e
> node {
>   child1 = a
>   child2 = b
>   child3 = c
>   3 = d
>   4 = e
> }
>
> (well, I didn't try it)... but, if you override like that, I guess
> that's what you get.
Sure, the patch didn't mean to change that. The purpose was to remove an
obscure corner-case, to make it more straight-forward and usable.

Since HDF doesn't support multiple values per node, there has to be some
compromise. And the current compromise is quite good. The patch fixes the
case were you weren't using a multi-value parameter, yet the ClearSilver
thought you did. In your example above, you *did* use a multi-value
parameter so the result is correct and per documentation.

On the other hand, in my project, I prefer another approach to multi-value
mapping, best described by an example:

node = a
node = b
node = c

Becomes:

node {
    a = 1
    b = 1
    c = 1
}

And for that matter:

node = group1.child1
node = group1.child2
node = group2.child3
node = child4

Becomes:

node {
    group1 {
        child1 = 1
        child2 = 1
    }
    group2 {
        child3 = 1
    }
    child4 = 1
}

This makes it easier to implement generic grouped options (using OPTGROUP).
I do this remapping after the ClearSilver interpreted the POST.

> I think your patch is fine, though compatibility... ugh.
I can't see a case where the dataset generated by the removed behavior
would be useful, so I don't think there is a problem.

Sincerely,
Nick