Ok, so $.param is explicitly called in $.fn.load, $.fn.serialize and $.ajax.
I really like the idea of adding "traditional" as a property in the $.ajaxSettings data object, as well as making it a second, optional argument to $.param. This is something I had considered at one point, but never implemented. I don't see any benefit to adding a "traditional" argument to $.fn.serialize, because form input names should always explicity include any necessary [], to allow for graceful dedgradation. How does this commit look? http://github.com/cowboy/jquery/commit/4ea851e08841447ba3550dc54785b3c026a5560f * $.ajaxSettings.traditional defaults to false, changeable by $.ajaxSetup({ traditional: true }); * $.fn.load and all other $.ajax XHR methods use the $.ajaxSettings.traditional property to determine their behavior, which can be overridden with $.ajax options. * $.param behavior defaults to the value of $.ajaxSettings.traditional but can be overridden by a second, optional argument. I also like the idea that "traditional" is false by default. It's relatively easy for anyone upgrading to 1.4 to set $.ajaxSetup ({ traditional: true }); in their code if they are encountering encoding issues, but for beginner PHP and Rails users (which seems to represent a substantial portion of the jQuery community) starting on 1.4, this will be one less AJAX question that they need to ask. Either way, it would be trivial to make the "traditional" flag to default to true, just as long as there *is* a traditional flag. Perhaps it would be useful to break down how request params are deserialized, by server / framework.. anyone? - Ben On Dec 21, 9:56 pm, Dave Methvin <dave.meth...@gmail.com> wrote: > > Does this mean that the default mechanism now changed, so that code > > which used to work will silently start failing? > > Yeah, I have some concerns about this. It's great to have $.param > facilitate PHP-friendly serialization, but I'd like to see the default > reversed to avoid breaking existing code. > > > The argument that "this helps PHP" could be countered by "this hurts > > java servlets", where request.getParameterValues("a") already returns > > an array for a (as in jQuery < 1.4), but needs to change for jQuery > > 1.4. > > This also breaks existing server ASP code, which already understands > that multiple params with the same name should be turned into an > array. > > Just another thought here; the flag being added is global, but it's > quite possible a page may be communicating with different hosts that > have different requirements. If different plugins have different needs > then it could get really messy having them bang around the same global > flag. > > Either as an alternative or addition to a global flag, .ajaxSettings, > the .ajax() options parameter, .param(), .serialize() and > serializeArray() could support an optional argument to decide how to > serialize the data. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
