flensed tweets
New @flensed feed!- (loading...)
| Subscribe to the flensed group | |
| Email: | |
| Visit this group | |
Quick Links
- jQuery flXHRproxy plugin
- Dojo flXHRproxy plugin
- Prototype flXHRproxy plugin
- Mootools flXHRproxy plugin
- Downloads
- Demo Examples
- Release Notes
- SVN Web Reader
- Secure SVN Repository
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!
Cross-Domain Ajax with Flash, not Ajax vs. Flash
flXHR [flĕkʹsər],(flex-er) is a *client-based* cross-browser, XHR-compatible tool for cross-domain Ajax (Flash) communication. It utilizes an invisible flXHR.swf instance that acts as sort of a client-side proxy for requests, combined with a Javascript object/module wrapper that exposes an identical interface to the native XMLHttpRequest (XHR) browser object, with a few helpful additions and a couple of minor limitations (see the documentation for more details).
The result is that flXHR can be used as a drop-in replacement for XHR based Ajax, giving you consistent, secure, efficient cross-domain client-to-server cross-domain Ajax communication, without messy workarounds such as br proxies, dynamic script tags, or server-side proxying.
flXHR brings a whole new world of cross-domain Ajax and API-consistency to any browser with Javascript and Flash Player plugin v9+ support (Adobe claims Flash has 99% browser support now). No other methods or workarounds can claim that kind of wide-spread support or consistency. In addition, flXHR boasts the ability to be dropped-in to many different Javascript frameworks (Dojo, Prototype, jQuery, etc) for even easier and more robust Ajax usage.
Here's a brief overview of flXHR's capability compared to other Flash-Ajax solutions:
| Feature | flXHR | Fjax | SWFHttpRequest | FlashXMLHttpRequest | F4A |
|---|---|---|---|---|---|
| cross-domain communication | X | X(1) | X(1) | X(1) | X(1) |
| automatic SWF embed | X | X(2) | -- | X(2) | X(2) |
| native XHR API compatible | X | -- | -- | -- | -- |
| easily integrated with JS frameworks | X | -- | X(4) | X(4) | X(4) |
| Flash plugin version compatible (3) | 9.0.124+ | 6+ | 9+ | 6+ | 8+ |
| Flash plugin auto-update | X | -- | -- | -- | -- |
| XHR API extensions, like robust error-callbacks, timeouts, etc | X | -- | -- | -- | -- |
(2) These libraries use more primitive, less mature/stable solutions, compared to flXHR's use of SWFObject 2.1 library.
(3) It may seem like a benefit to have more backwards-compatibility, but actually, since the later plugins have had better security and better communication efficiency, the later the plugin version leveraged, the better the solution will ultimately be. flXHR is the only one to specifically leverage the full security model just implemented with the 9.0.124 plugin release.
(4) While these solutions can be integrated with some frameworks under special circumstances, they each have limitations which will prevent this consistently from working in all frameworks, all browsers, and in all circumstances. flXHR is much more robust, and will work under any number of circumstances and with virtually any JS framework which is already XHR-aware.
Here's a brief overview of flXHR's capability compared to XHR and other non-flash client-side cross-domain workarounds:
| Feature | flXHR | XHR | br | <SCRIPT> |
|---|---|---|---|---|
| interoperable with major Javascript frameworks | X | X | X(1) | X(1) |
| cross-domain requests | X | X(2) | X | X |
| --> robust author/server security authorization | X | -- | -- | -- |
| --> consistent cross-browser usage | X | -- | -- | -- |
| response event driven (readyState, etc) | X | X | -- | X(3) |
| response content-type agnostic | X | X | X | -- |
| callback error handling | X | -- | -- | -- |
| timeout event handling | X | X(4) | -- | -- |
| robust memory management compatible | X | X | -- | -- |
(2) XHR in the new FF3/IE8 generation will support this, but the implementation and usage details are not going to be consistent, which will require custom browser-dependent code to create a consistent usage interface. It's not supported natively at all prior to the next-gen browsers.
(3) Depending on the type and style of content sent back from the server, the eval()'d Javascript/JSON code can set itself to automatically execute once it fully loads, simulating the response event-driven behavior.
(4) IE8 has announced support for the timeout event and ontimeout handler. Unknown support for FF3. Not supported directly (that is, without custom code logic around it) in any other browsers.
As you can see, for the most part, flXHR implements an XHR API-compatible interface with a pile of extra/enhanced functionality, including most notably, direct non-proxy'd cross-domain client-to-server communication.