the Fresh!

In the wake of the jQuery flXHRproxy and Dojo flXHRproxy plugins recently released, Prototype was unfortunately left out of having a good solid plugin for flXHR… until now!

Austin resident Prototype guru Andrew Dupont recently wrote an initial version of the plugin, which I then modified and tested, and we now have a great plugin for Prototype to support flXHR in the same way as the other frameworks.

Just like with the other framework plugin versions, you simply call ‘registerOptions(…)’ to register a URL (or partial URL) destination target and a set of flXHR options to be used for that location. Then, when you later make various Ajax calls, Prototype will internally figure out if you are calling to a location that is registered and will use flXHR with the options you specified.

There is simply no other way to get easier cross-domain Ajax with Prototype than with flXHR and flXHRproxy. Take a look at flXHRproxy documentation or give the Prototype+flXHR demo a whirl.

Typical page usage might look like this:

Ajax.flXHRproxy.registerOptions('http://www.mydomain.com/',{xmlResponseText:false...});
Ajax.flXHRproxy.registerOptions('http://rss.mydomain.com/',{xmlResponseText:true...});
...
Ajax.Request('http://www.mydomain.com/something.html',{...});
...
Ajax.Request('http://rss.mydomain.com/feed.html',{...});


Enjoy the new world of possibilities and fun that Prototype and flXHRproxy now gives you for doing easy cross-domain Ajax!

Back in march, I announced the jQuery plugin for flXHR, simply the best way to do cross-domain Ajax with jQuery. It has enjoyed huge success in traffic/downloading since, and that proves that there are lots of people out there who are doing cross-domain Ajax with frameworks like jQuery and Dojo, and that people are craving for better, easier and more flexible ways of doing so. flXHR is the answer to your cross-domain Ajax woes.

Building on the success from the jQuery plugin, I’m now pleased to announce that I’ve released a Dojo plugin for jQuery which is nearly identical in functionality. Basically, all you have to do is load the ‘flXHRproxy’ Dojo plugin, and then call ‘registerOptions(…)’ to register a URL (or partial URL) destination target and a set of flXHR options to be used for that location. Then, when you later make various Ajax calls, Dojo will internally figure out if you are calling to a location that is registered and will use flXHR (or any other transports you register!) with the options you specified.

If you use Dojo, and you do cross-domain Ajax calls, I urge you to consider flXHR and flXHRproxy. Take a look at flXHRproxy documentation or give the Dojo+flXHR demo a whirl.

Typical page usage might look like this:

dojox.io.flXHRproxy.registerOptions('http://www.mydomain.com/',{xmlResponseText:false...});
dojox.io.flXHRproxy.registerOptions('http://rss.mydomain.com/',{xmlResponseText:true...});
...
dojo.xhrGet({url:'http://www.mydomain.com/something.html'...});
...
dojo.xhrGet({url:'http://rss.mydomain.com/feed.html'...});


This XHR registry concept is very powerful, as it allows you to have multiple different types of Ajax calls and transports and configurations for different types of data that you are mashing up in a single page. It takes all the guess work out of configuring your code to intelligently use the right communication method and options as needed for each Ajax call. It just simply could not get any easier to do cross-domain Ajax calls with Dojo now.

Enjoy the new world of possibilities and fun that Dojo+flXHR now gives you for doing easy cross-domain Ajax!

PS. Teaser: Coming soon, flXHR+YQL = cross-domain Ajax to literally any site on the internet! How cool is that!?

So, this is just a quick post to share some information which was worked out recently in an email thread with a flXHR user. Because it’s probably a somewhat common pattern (albeit, mostly for more complex Ajax apps), I figured it would be helpful to share the information here, just in case anyone else runs up against similar issues.

flXHR has a feature called instancePooling, which is very helpful for performance/efficiency improvement reasons, especially with pages that make multiple Ajax requests. The way it does this is to keep around instantiated references of flXHR in a “pool”, and when a new instantiation is requested, if an available instance in the pool is idle and ready (that is, it’s already been used and is in readyState = 4), then it will reuse that instance (and reconfigure it as necessary) instead of creating a whole new one.

There was a bug fixed in 1.0.3 regarding flXHR’s ability to fully reconfigure a reused instance. So, if you’ve tried that type of thing prior to upgrading to 1.0.3, you should upgrade to get the expected behavior.

Anyway, this feature is almost universally necessary when doing Ajax calls with frameworks like jQuery, Dojo, Prototype, etc, because these frameworks tend to “throw away” XHR instances after single use, but with flXHR, it’s better to keep them around to avoid the “penalty” of instantiation on subsequent requests. So, rather than try to modify the way the frameworks work, flXHR makes this transparent with the opt-in “instancePooling” configuration option. I would estimate in probably 99% of all Ajax applications, this is the option you would want to keep memory-usage and instantiation times down. Unless you specifically know better, I would recommend *always* using it.

Now, as the title of this post suggests, there is a common pattern for a lot of medium-to-high complexity Ajax apps where the author of a page may need to “chain” Ajax calls — that is, make one Ajax call, and then upon completion of the first one, make another Ajax call from the response handler of the first.

It is when you combine these two concepts that a devious little “issue” creeps in. I’ll try not to go into lots of gory detail here, but the bottom line is, if you make an Ajax call from a response handler of a previous Ajax call, and you have instancePooling turned on, a race condition exists with the way framework code works which will cause issues, most notably that the handler may not get properly called on your second “chained” request, even though the full response does get back to the browser.

Read on to find out the details and how to fix it.