#4 looks fine to me.
On #1 and #2: perhaps the answer is...
{ foo: undefined } => "foo="
{ foo: null } => ""
I don't know if this is useful or not, but it would allow you to
distinguish between these two cases, since null and undefined are
distinct values with different meanings.
I have no opinion on #3. That's an edge case that makes my brain cry.
Cheers,
Andrew
On Mar 2, 10:48 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> I'm combining Tobie's and mine Hash patches to see how they work out. These
> changes fix 3 bugs and remove some premature optimization from toQueryString
> method. Now, ticket #7494 by Skirch is about nested hash support - I like it
> and am thinking about rolling it in for the next release. There are a number
> of questions regarding all these changes, though. I'd like to sort out the
> inconsistencies.
>
> 1. undefined (or null) values are currently serialized as empty
> strings - should those key/value pairs be skipped instead?
> 2. undefined (or null) values are currently skipped if they're inside
> an array value - should it be consistent with #1?
> 3. should array values be flattened when serializing? (#7494 does
> this)
> 4. should we support nested hashes?
>
> Same questions expressed in JS code:
>
> 1. { foo:null } => "foo="
> 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"
>
> Remeber, the toQueryString is all about sending that data to the server. The
> result strings are also used inside Prototype to check if the form has been
> modified.
>
> Please, state your opinions.
>
> --http://dev.rubyonrails.org/ticket/7494
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: 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/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---