If we are talking about form serialization, then when is it even
possible to have null or undefined values?  Form.serialize grabs all
form elements, so if it does it's job correctly then undefined is out
of the picture. On FF (haven't tested else where or looked up specs)
the .value property cannot be null.. create a new element and don't
assign it a value and it will evaluate to "" already. Even when I
manually assigned it to null it still evaluates to "". Is there a case
in which a form element's value can be null? Before you say "the user
can define null and undefined values directly in a hash", read on.

Creating arrays in an HTML form is really just a hack, defining
elements with the same "name" value repeatedly.. As we've seen,
interpreting this is not a well-defined operation. For example, a PHP
programmer (or others) may intend for one element's value to override
another if present by reusing the name without brackets while a Rails
programmer would expect an array. It seems like forms are better
represented as a collection of independent key->value pairs rather
than a hash, which are not the same things.
1) A hash is not guaranteed to maintain the original order in which
the elements were defined, and
2) a hash is composed of unique keys that have one value.
Serialization and deserialization of a collection of such key->value
pairs would be completely straightforward, and I suggest this is the
way it should be done. This is the only truly server-agnostic solution
IMO. I would then suggest providing a separate method for interpreting
that collection either as a strict hash, or as a hash with nested
arrays in the case of multiple definitions of the same key.

//PHP users would most *likely* use strict = true
//default result is same as current serializeElements([],true)
collectionToHash: function(collection, strict){
  return collection.inject({}, function(result, pair) {
    if (!strict && pair.key in result) {
      if (result[pair.key].constructor != Array) result[pair.key] =
    }else result[pair.key] = value;
    return result;

Doing the above would then allow for much better flexibility in
toQueryString and toQueryParams.. i.e. "real" arrays would be given
indexes and then any combination of arrays and hashes would be
possible with the caveat that some server-side languages will
interpret numerical indexes as hash keys rather than array indexes but
as I already said, that is a shortcoming of the server-side

Of course, code could be shuffled around a bit so that backwards
compatibility is maintained.. for example, serialize could get another
optional parameter which would simply be passed on to
collectionToHash, but for internal use, direct serialization of a form
to a collection to a string wouldn't care.


Thoughts? Basically I am separating Hash.toQueryString from
Form.serialize because forms are not most accurately represented as
hashes to begin with, putting the question of server-side or intended
interpretation out of the picture and therefore allowing toQueryString
to do it's thing independently of form serialization.

I'd be happy to write up a patch that fully implements what I've
proposed if the core team is interested.


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