Also, inspired by the code we worked out for the Mootools plugin, I have released updates to the jQuery plugin, Dojo plugin, and the Prototype plugin. These three plugins now play nicely with each respective framework’s built in error mechanism for normal Ajax calls.

Prior to this release, error handling was only possible by manually setting the “onerror” property in the flXHR instance configuration properties. This same functionality is still supported. But now the recommended approach is to specify your error callbacks directly in your Ajax/Xhr calls as you normally would. Note: Do only one or the other, not both, to avoid duplicate callback execution in some circumstances.

Now that flXHRproxy is more tightly integrated with each framework’s event mechanism, the ease with which you can make cross-domain Ajax calls just keeps getting better and better! Really, what excuse do you still have for not using flXHR for your next cross-domain Ajax call?

One last note: the jQuery update also includes one additional change. The “success” callback function signature is now extended to include a third parameter, which is set to the flXHR instance (XHR) that generated the call/response. This makes it much easier to determine which specific Ajax call the response comes from.

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!

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!?

I made some recent optimization changes to the site according to suggestions from YSlow. (side note: I went from a 27-F grade to a 62-D grade with some simple CSS, HTML, and JS changes — not bad, huh?). Anyway, one of the changes I made regarding Javascript was to package all 4 flXHR related JS files into one file (flXHR.js, checkplayer.js, flensed.js, and swfobject.js), to reduce the number of HTTP requests on page load.

After rolling out those changes and basking in the glory of my optimization improvements, I realized that part of my code logic, the part about reversing URLs, wasn’t working anymore, even though all the rest of my jQuery code logic seemed to be working fine. After some clumsy debugging, I found out it was because flXHR was never fully loading (actually, all the JS was there, obviously, but the other assets, like flXHR.swf) were not loading.

When this happens, it’s USUALLY because the code is unable to auto-detect the correct base-path to load additional assets from. The code is able to do the auto-detect by looking for itself (that is, its corresponding DOM script tag) and inspecting the path of the file reference. But the logic only works if the file is the same name as what it’s hard-coded to look for (“flXHR.js”).

In my haste to package up the files, I named the new file “flXHR-packaged.js”. Thus, the base-path detection went lame. Oops. Luckily, there’s a simple fix, and doesn’t require any hacking to the files at all (probably the easiest temptation — but you should avoid that IMHO).

All you have to do is include a setting to manually specify the base-path for flXHR/flensed to use, and all’s good! Look:

<script>var flensed={base_path:”/path/to/flXHR.files/”};</script>

Include that right before your script tag that includes flXHR.js (or whatever you are calling it), and you should be fine.

Note: Make sure you use regular double-quote characters instead of the funny stylized ” that WP insists on using.

Happy flXHR’ing.

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.