For anybody interested, this patch has been updated such that the new UrlEncodedPairParser implementation is pluggable (i.e. applications that rely on the behavior of the old parser can now opt to use the old parser).
This is the best of both worlds: forms become easier for developers to manipulate in new applications, but developers who rely on the old behaviour can keep their existing applications working as normal. See this lighthouse post for the patch & the details: http://rails.lighthouseapp.com/projects/8994/tickets/1142-simplified-parameter-parsing-code#ticket-1142-8 Any further feedback would be much appreciated. Cheers, Tom Thomas Lee wrote: > Hi Mislav, > > By adding a little hack here and there, I can get very close to the > original semantics such that only one or two tests would fail. In the > patch, I opted to change the tests rather than the parser code to get > them passing since most of the failing tests are checking the behaviour > of the parser on invalid inputs (where I'd argue the garbage in, garbage > out adage applies). Also, I wanted to avoid introducing hacks to the new > parser before it was deemed necessary. > > I agree though, backwards compatibility is important. I'm perfectly > willing to concede that changes will need to be made to assure some > level of backwards compatibility, although I'd still argue that testing > the output of the parser for any set of invalid inputs is a waste of > time since the options are: > > 1. Bad output. > 2. No output. > 3. An error. > > I don't think a single parser could support both schemes due to the old > parser's treatment of "foo[0]=5" as {"foo" => {"0" => "5"}}, and the new > parser's treatment of the same thing as {"foo" => ["5"]}. Having said > that, maybe it could be a Rails::Configuration setting if need be? > > Cheers, > T > > Mislav Marohnić wrote: > >> When these issues (with the original parser) were first raised because >> of prototype.js parser being different, and yet yielded the wanted >> results, I first opposed them. Lately I've seen how they could tighten >> up and improve complex forms. >> >> Having said that, I'm worried about backwards-compatibility. I don't >> think a single parser can support both schemes -- or am I wrong? >> >> > > >> Still, should there be a switch one can toggle to start using the new >> parser after Rails 2.2? >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
