Parameter Parsing with Duplicate Parameters

[MacProBob]

Wondering if this should be the correct behavoir of parameter parsing
in Rails.

GET /controller/action?key=value1&key=value2

puts params['key'] # = value1

Currently, if you pass in multiple values with the same key, the FIRST
value is the value that is used and available in params. I think this
goes against PoLS in that keys defined later in html or on the query
string should override any previously defined values for that key. I'm
not referring to the ability to create an array using the [] syntax.

There is no written specification for how to parse incoming data, but
it seems logical that you would want the values defined later to be the
values you retrieve from your framework. (Most other web technologies
follow this behavoir as well, PHP, Django, all the Java crap etc..)

Opinions on this behavoir? I can do up a patch to enable it, not sure
what BC effects this would cause since you can't really rely on this
behavoir right now anyways.

Bob Silva
http://i.nfectio.us/

[bitsweat (Jeremy Daer)]

Take a look at the checkbox form helper. It effectively exploits the current behavior.

jeremy

[MacProBob]

Hi Jeremy,

For the checkbox code, I wouldn't define that as exploiting the
behavior, it's more like working around the problem. If Rails exhibited
the "typical" behavior for parameter parsing (treating the incoming
parameters as a hash where new values overwrite existing ones), the
hidden field would just be listed before the checkbox tag instead of
after it.

I was just wondering why the break from convention and if it was a
design decision or an oversight and something that can be fixed.

Thanks for the reply. I'll just wrap it up in a plugin.

Bob Silva
http://i.nfectio.us/

Jeremy Kemper wrote:

[bitsweat (Jeremy Daer)]

For the checkbox code, I wouldn’t define that as exploiting the
behavior, it’s more like working around the problem. If Rails exhibited
the “typical” behavior for parameter parsing (treating the incoming

parameters as a hash where new values overwrite existing ones), the
hidden field would just be listed before the checkbox tag instead of
after it.

Ah, you’re totally right. Could go either way.

I was just wondering why the break from convention and if it was a
design decision or an oversight and something that can be fixed.

It was a design decision, but I think your expectation is reasonable.

jeremy