[Prototype-core] Form.serialize, Ajax.Request, Hash.toQueryString, "".toQueryParams
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 , 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
-~--~~~~--~~--~--~---
[Prototype-core] Ajax.Updater and Cacheability
Hi all, (I am reposting this from the spinoffs list by request from the only response received there) It seems to me that as AJAX applications mature and become more popular, many Prototype deployments will require some sort of caching layer. Perhaps some would say that caching belongs outside of Prototype, however I believe that putting it inside deserves consideration for the following reasons: 1. More and more projects will require caching functionality 2. The functionality wouldn't require much code. 3. HTTP header values in server responses could potentially be useful (as in standard web apps) to control client-side cache expiration (see CacheableUpdater below). Furthermore I suspect that implementing caching externally as a wrapper for Prototype would preclude the use of these headers. Therefore I think extending the Prototype library with caching support is worthy of consideration. To illustrate, something like a couple of alternative methods to Ajax.Updater could be implemented... Ajax.SingleUpdater - Fetches the URL once, then returns the same content on subsequent calls with the same URL. Ajax.CacheableUpdater - Respects standard HTTP 'Expires' / 'Pragma' headers when deciding whether to re-issue an HTTP request or return the last content fetched. Thoughts? - Walter PS: AFAIK the list past posts only have one ruby code snippet related to caching, nothing language-agnostic at the Prototype/JS level... as it happens we use PHP (our app needs strong unicode support, including regexes.) PPS: For those interested, our usage scenario is as follows. The app we are currently developing a lot of input fields are both multilingual and of an arbitrary number. We are using dynamic, javascript-generated input field sets to provide an elegant UI solution, but have MANY such fieldsets on our pages. Therefore loading the (long) list of languages via Prototype only once, then re-using it, would be an excellent optimisation for a) initial page size b) UI responsiveness At present, with 'pure' Prototype Ajax.Updater re-issues the HTTP request each time an instance of a multilingual field is created. Sure, we could implement a once-off caching solution, but shouldn't this more generic problem be solved closer to home in Prototype? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: $$() and checkboxes checked property
Sorry, yeah that would be important information :). I'm using Prototype version 1.5.0_rc1. I tried using 1.5.0_rc2, but I got an error saying "Stack overflow at line: 0". The web browser is IE7. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: SyntaxError object missing.
Ahh I see my Firebug picks it up. IE is silly about it (doesnt give the error message says "an exception was thrown but not caught"). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Dean Edwards new library
Hey, Mislav Marohnić a écrit : > Danger. The page loads 2.5 MB of scripts and dojo.js makes tens of XHR > (synchronous!) requests which all result in 404s (!). This can seriously > hurt your browser! WTF is Dean doing? This page goes against every principle of pageload efficiency! It's not like him at all... It took my browser 1.24min for 512 requests to load this thing. The Firebug Net view for it is hilarious. At any rate, it will be interesting to look at his code. -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: $$() and checkboxes checked property
Hey again (sorry for the double reply, forgot another question), Christophe Porteneuve a écrit : > Which exact version of Prototype are you using? ...and what exact browser(s)? (Important as it lets us know whether you rely on Selector's XPath or JS impl.) -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: $$() and checkboxes checked property
Hey there, Which exact version of Prototype are you using? -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
