Hey Mislav,

According to the talk we had in Core's campfire, and to the way Rails 
seems to behave, here's my take on your examples.

> 1. { foo:'', bar:null } becomes "foo=&bar=".

> 2. { bar:undefined } is skipped

> 3. for now, "a=b&bar" becomes { a:'b', bar:undefined }. That should
>    be null instead, right?
Yes.  Since we skip undefined on the way out, we should consider 
presence on the way in to mean null.

> 4. "foo=a=b=c" becomes { foo:'a=b=c' }
Totally (is this even a valid URL component though?).

> 5. it handles "&a=b&&&&c=d" properly, too
That is, how?  I figure { a: 'b', c: 'd' }...

> regarding the square brackets, but I don't think we are to follow that 
> because we are at the client, not the backend. Magic around square 

I sort of agree.  I think we *may* use brackets in the QS as a hint that 
it's an array, but we should not put brackets on the way out.  J2EE, for 
one, doesn't require any (and as you mentioned way back, URL-encoded 
brackets in the parameter name look "like a car wreck" :-)).

Just a thought: optional argument to put brackets in?  But this sounds 
very much like edge case to me, since putting brackets in the form 
element names will be preserved anyway, and we're just talking about 
serializing a random object here...  Plus, at any rate, later-coming 
serialization hooks will let people do that anyhow.

> 1. { foo:['a', 'b', 'c'] } becomes "foo=a&foo=b&foo=c".

> 2. "foo=a&foo=b&foo=c" becomes { foo:['a', 'b', 'c'] }. Rails (PHP
> too, I think) would preserve only the first value. Ruby preserves all.
As do J2EE and, I believe, .NET.  Backend-agnosticity mandates we deal 
with this like HTTP and HTML intended us to, which is what you're 
describing here.

> 3. "foo[]=a&foo[]=b&foo[]=c" becomes { 'foo[]':['a', 'b', 'c'] }.
>    Rails and PHP would now preserve all values, but remove the square
>    brackets from the key.

That's a backend concern, we don't need to be concerned with that.  It 
is paramount that we do not automagically alter any key name, otherwise 
we'll break form serialization.  As I mentioned, later serialization 
hooks will deal with edge cases.

> 4. { foo:[null] } becomes "foo="
OK.  Totally consistent.

> 5. { foo:[undefined] } or { foo:[] } becomes ""
OK?  Consistent yet somehow feels weird...  On the other hand, bijection 
mandates this result.

> 6. "color=&color=blue" now becomes { color:['', 'blue'] }, not {
>    color:'blue' } as before.
OK.  Prime case of lack of bijection in the 1.5.0 implementation.

Christophe Porteneuve aka TDD

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 

Reply via email to