Quick Links
Known Issues
- 17 Sept 2009 Issue #20
- 6 Jan 2009 Issue #13
- 18 Sept 2008 Issue #5
- 14 June 2008 the Flash Player plugin doesn't (yet) support synchronous communication, so the 'asynch' parameter to open() is ignored.
- 14 June 2008 the Flash Player browser plugin cannot (yet) access any response headers, so the getResponseHeader() and getAllResponseHeaders() functions are just stubs that return no content.
Adobe Issue #251
HINT: GO VOTE FOR THIS BUG SO IT GETS FIXED!
flXHR jQuery plugin
While you can already adapt jQuery to use flXHR by overriding the 'xhr' setting in the Ajax Options, it doesn't give you much intelligence or flexibility in customizing your flXHR configuration options for different requests. It works for simple pages with only one (or one type of) request, but as soon as the page needs more sophistication, or when you want flXHR used only for some of your page's requests, you need something more sophisticated.
So, the 'flXHRproxy' plugin, which utilizes the new jQuery 1.3 XHR Registry, registers flXHR as an Ajax XHR variant so you can tell the core jQuery library to use flXHR under more complicated configuration options. It is considered the best practice at this point for adapting jQuery to use flXHR.
Specifically, this plugin uses the registry to associate a particular set of flXHR options with a specific unique URL (or partial URL). The registry will then automatically use flXHR (and those associated options) for any Ajax request that uses the 'flXHRproxy' transport and which matches that target URL or partial URL.
Note: Starting with v1.2 of this plugin, integration with the "error" event handling of the native $.ajax part of the framework is now working. This means that it's now preferred that you specify your error handler in your $.ajax or $.ajaxSetup call rather than in the flXHR properties. Either will work the same, but tighter integration with the framework is of course preferred. You will continue to get a rich error object (with flXHR extended properties) passed to that handler, regardless of how you specify the event callback.
Also, in v1.2, the function call signature for the "success" handler has been improved. The first two parameters are unchanged, but now a third parameter is now passed, which is the flXHR instance (XHR) used for that call. This makes it much easier to determine which Ajax call was responsible for the response you are processing.
Read more about 'registerOptions(...)' and jQuery transport selection
Because flXHR is completely API compliant to normal native XHR Ajax, you will not need to change any of your other jQuery code. You simply register flXHR on page load and jQuery core and the XHR Registry will take care of the rest. How much easier could cross-domain Ajax be?
Documentation can be found here.
The official plugin homepage can be found here.
A working demo can be found here.