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 Dojo plugin
While you can already adapt Dojo to use flXHR by overriding the '_xhrObj' factory function to return a flXHR instance instead of a native XHR object instance, 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 DojoX.io | XHR Plugins extension, registers flXHR as an Ajax XHR variant so you can tell the core Dojo library to use flXHR under more complicated configuration options. It is considered the best practice at this point for adapting Dojo 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 select and use flXHR (and those associated options) for any Ajax request which matches that target URL or partial URL.
Note: Starting with v1.1 of this plugin, integration with the "error" event handling of the native Xhr part of the framework is now working. This means that it's now preferred that you specify your error handler in your Xhr 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.
Read more about 'registerOptions(...)' and Dojo
Because flXHR is completely API compliant to normal native XHR Ajax, you will not need to change any of your other Dojo code. You simply register flXHR on page load and Dojo core and the XHR Registry will take care of the rest. How much easier could cross-domain Ajax be?
Documentation can be found here.
A working demo can be found here.