the Fresh!

Another quickie to detail a little gotcha that I just ran into on this site, actually. I use flXHR on this site to make requests to longurlplease to lengthen/reverse shortened URLs (mostly in the recent tweets feed). I use the flXHRproxy jQuery plugin with jQuery code to accomplish 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.

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.

I’m excited to announce the public release of the flXHRproxy jQuery plugin, which registers flXHR for use with the jQuery XHR Registry plugin. The XHR Registry Plugin, along with flXHRproxy, allows you to associate a set of flXHR options with a matched URL or partial URL for each Ajax request’s target. So, you can have different data types (XML, JSON, etc) from different URL locations, each with its own set of flXHR options.

All you have to do is set up the configurations on page load, and then the rest of your jQuery Ajax code is totally unchanged, as the core of jQuery and the XHR Registry will take care of doing all the matching for you automatically. It also means that it is very easy to use flXHR only for cross-domain Ajax calls and native XHR (or other methods) for other (same-domain) calls. This is a commonly asked for feature and was much harder to do before this plugin was built. flXHRproxy is now the best-practice method for integrating flXHR with jQuery.

You can read more about the new plugin here.

Also, flXHR and CheckPlayer both have patch versions released today. All users are encouraged to upgrade to the latest releases.