On Mar 18, 2007, at 9:13 AM, Mislav Marohnić wrote: > On 3/16/07, Tom Gregory <[EMAIL PROTECTED]> wrote: > > This problem didn't exist (at this volume level) until Prototype > started serializing Forms as Hashes instead of query strings > > What problem? I thought we were merely discussing about conventions > and which to embrace/discard.
I think you're being creatively forgetful. I'm referring to the topic that started this thread, which you posted: How does one appropriately turn complex JS objects into query strings? http://groups.google.com/group/prototype-core/msg/1127daf06a040a9b A good rewrite of Hash.toQueryString would have brought the discussion about eventually, but the transition to Form serialization as hashes made the issue both more immediate and more pressing. > ... which led to the problem of figuring out how to represent two > inputs with the same name > > When Prototype serialized forms to query string, those two inputs > looked like this: > > "foo=1&foo=2" Which is correct behavior. We both know that. > .. and nobody complained. Now that we serialize using > Hash.toQueryString , the same form inputs look like this: > > "foo=1&foo=2" > ... and everybody complains! Suddenly you all want to replace the > whole thing with JSON! :) > > Remember, we've covered form serialization a long time ago. It > works. Now we're just polishing and trying not to break stuff It's not the Form serialization I'm worried about. The question is Hash serialization, which involves more edge cases, as you've demonstrated. I'm suggesting that it would have been very easy to serialize any complex objects beyond the first level as JSON. However, serializing Forms as Hashes means we have to be able to make a round trip, so the solution can't be that easy. Tweak the idea to allow for arrays at the first level (but not nested), no nested hashes at all, anything that's not a primitive is converted to a string (Hashes and Arrays use toJSON(), other objects (e.g. Date) use implicit toString conversion.) To go back to your original question (after thinking about it a good deal, I'm giving a different answer than I originally did): > 2. { foo:['a', null, 'b']} => "foo=a&foo=b"; { foo:[null] } => > "foo=" > 3. { foo:['a', ['b'], 'c']} => "foo=a&foo=[object]&foo=c" > 4. { foo:{bar:'baz'}} => "foo[bar]=baz" 2. "foo=a&foo=&foo=b" // if We maintain that foo: null => "foo=", per #1 3. "foo=a&foo=" +["b"].toJSON() + "&foo=c" 4. "foo=" + {bar:'baz'}.toJSON() Re #4, I'd suggest that if the programmer wished the result to be "foo [bar]=baz", then the original hash should be { "foo[bar]" : "baz" }. This solution gives a mostly 1:1 relationship between input and output--the operation is reversible. I say "mostly", because null == "", and both would unserialize to "", however (un)serializing boolean values might not be completely reversible--I haven't tested. TAG --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
