I started a new thread on this since it was getting quite long and I
now have a new take on the subject.
The changes to these functions introduced in 1.5.1 have broken a few
things, no doubt about that. The problem is Ajax.Request always
converts parameters into a Hash, making *assumptions* along the way
about how to serialize and deserialize it. It is very disconcerting to
pass in your parameters string and something else entirely gets passed
to the server. The only way one can guarantee string is not fouled up
is to change "parameters:" to "postBody:" everywhere, but I believe
this really shouldn't be necessary. At the bare minimum, the behavior
of "parameters" should be documented to warn that it's use with a
string could result in changes to your final query string but
preferably a string would remain a string throughout.
About these assumptions, I am talking about the difference between:
'foo=bar&foo=baz' => {foo:['bar','baz']}
'foo=bar&foo=baz' => {foo:'baz'}
and also
{foo:['bar','baz']} => 'foo=bar&foo=baz'
{foo:['bar','baz']} => 'foo[0]=bar&foo[1]=baz'
Which will work is dependent entirely upon your server-side platform.
For form encoding, the only thing we know is in the case of <select
multiple>, the name is repeated and no brackets are added. So, the
default behavior should be to not add brackets, and certainly in the
case of form serialization, as it is important to mimic the browser's
own serialization as closely as possible.
So, Form.serialize(form) returns a string directly (without building a
hash first). This gets rid of the first problem when serializing forms
to a string.
Now, when Form.serialize returns a hash, I added an additional
parameter that will determine which method will be used in decoding
the string. I call the latter method "strict", because when in strict
mode, pre-existing keys are reassigned rather than converted to arrays
so the result is strictly a hash of keys->values. The default is
consistent with the original API and with Rails. If form names have
brackets appended manually it will still be compatible here as well.
Similarly, if you expect your duplicate keys to be converted into
arrays then you probably want your arrays to be decoded back into
duplicate keys. This poses a great limitation on the power of
toQueryString since nesting anything inside an array would be
impossible to encode and decode without adding indexes explicitly. For
example:
{options: [
{text: 'First option', value: 24},
{text: 'Second option', value: 56}
],
default: 24
}
This can only be properly encoded as
options[0][text]=First+option&options[0][value]=24&options[1]
[text]=Second+option&options[1][value]=56&default=24
My solution to this was to check the array in question, if it has
nested arrays or hashes, I add an index manually, otherwise I don't.
Since HTML forms will never have nested arrays this works perfectly
for everyone but still allows you to do nesting like in the example
above. I also added an optional parameter to toQueryString that will
always add brackets so that platforms that require them don't require
hacking up your object keys. The default again, is consistent with the
original API and Rails and for form serialization will produce the
correct result each time.
I've also removed the use of $H functions from toQueryString for
compatibility with keys such as "each", "collect", etc..
Test page for form serialization: http://colin.mollenhour.com/querytest.php
Test page for hash->string->hash conversion:
http://colin.mollenhour.com/toquery.php
Code: http://pastie.caboo.se/48953
Thoughts, opinions?
I suppose some of you won't like the extra parameters, but without
them it is really limiting the usability of these functions in many
cases.
Thanks,
Colin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
