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/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On 8/23/06, MacProBob <bobtheslob@gmail.com> wrote:> > 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.Take a look at the checkbox form helper. It effectively exploits the current behavior. jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
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:> On 8/23/06, MacProBob <bobtheslob@gmail.com> wrote: > > > > 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. > > > Take a look at the checkbox form helper. It effectively exploits the current > behavior. > > jeremy > > ------=_Part_74073_1902035.1156399564123 > Content-Type: text/html; charset=ISO-8859-1 > X-Google-AttachSize: 1475 > > On 8/23/06, <b class="gmail_sendername">MacProBob</b> <<a href="mailto:bobtheslob@gmail.com">bobtheslob@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > Wondering if this should be the correct behavoir of parameter parsing<br>in Rails.<br><br>GET /controller/action?key=value1&key=value2<br><br>puts params[''key''] # = value1<br><br>Currently, if you pass in multiple values with the same key, the FIRST > <br>value is the value that is used and available in params. I think this<br>goes against PoLS in that keys defined later in html or on the query<br>string should override any previously defined values for that key. I''m<br> > not referring to the ability to create an array using the [] syntax.<br><br>There is no written specification for how to parse incoming data, but<br>it seems logical that you would want the values defined later to be the<br> > values you retrieve from your framework. (Most other web technologies<br>follow this behavoir as well, PHP, Django, all the Java crap etc..)<br><br>Opinions on this behavoir? I can do up a patch to enable it, not sure<br> > what BC effects this would cause since you can''t really rely on this<br>behavoir right now anyways.</blockquote><div><br>Take a look at the checkbox form helper. It effectively exploits the current behavior.<br><br>jeremy > <br></div></div> > > ------=_Part_74073_1902035.1156399564123----~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On 8/23/06, MacProBob <bobtheslob@gmail.com> wrote:> > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---