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 Mootools plugin
While you can already adapt Mootools to use flXHR by overriding the 'Browser.Request' class to return a flXHR instance instead of a native XHR 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 allows an author to register (associate) a particular set of flXHR options with a specific unique URL (or partial URL). The framework is extended so that it will then automatically use flXHR (and those associated options) for any Ajax request that matches that target URL or partial URL.
Read more about 'registerOptions(...)' and Mootools
Because flXHR is completely API compliant to normal native XHR Ajax, you will not need to change any of your other Mootools code. You simply register flXHR on page load and Mootools core 'Request' 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.