the Fresh!

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.

I am excited to announce the immediate release of flensed 1.0 (the 1.0 production ready releases of flensedCore, CheckPlayer, and flXHR).

All users are encouraged to upgrade immediately and to begin using this code for production projects.

Also, check out an overview of important changes/additions to the flensed family of projects with this 1.0 release.

[UPDATE: flensed 1.0 was released a few days ago, and is now fully tested and production ready!]

The release of flensed 1.0 is very near (mere days at this point)! The rc2 release (ZIP or TAR.GZ) has been out for several days now and being tested, and thus far seems really stable. So I thought this was a good time to discuss some of the changes that have come about over the last couple of months of me tinkering with the projects’ code.

1. Significant code cleanup: I consolidated all 3 projects with a full ‘module’ pattern implementation. This means that there is very clean, tight namespace management, and variable scoping is clear (with the explicit use of ‘global’ parameter). Also, it allowed a very strong emphasis on the use of convenience variables for frequently referenced strings, object names, etc. This not only makes source code reading easier, it also significantly aids in the JS minification/compression (YUI Compressor).
2. Fixes to ‘visibility’ and CSS management: I included an enhanced version of createCSS (from SWFObject 2.2a), which significantly improves the way that all the projects add CSS rules to the page dynamically. In addition, CheckPlayer manages ‘visibility’ settings of embedded SWF’s in a more straightfoward way that prevents issues with ExternalInterface registration bugginess.
3. Fixes to flXHR strict policy management: ‘PolicyChecker’ was the class added to flXHR.swf in a previous alpha release to address the needs discussed in this blog on security model holes. However, it was discovered through further testing that IP addresses, single-word domains (like ‘localhost’), and other such access entry-points were not being properly authorized/resolved with the implemented code logic. So, those bugs have been resolved, and the ‘PolicyChecker’ now properly enforces all the strict rules on SWF-domain and page-domain authorization as advertised.
4. Increased ‘open-source-ness’ of the SWFs: flXHR.swf and updateplayer.swf both previously used to only be compile’able through use of the Flash IDE and the proprietary .fla source files. However, work has been done to adapt the source code for these two SWF assets so that they can be compiled using free open-source SWF compilation utilities like ‘mxmlc’ (Flex Builder SDK) and ‘mtasc’ (Motion-Twin Actionscript Compiler). This means that if authors should ever need to tinker with these assets, they can edit the .as source files and recompile them for free, no need for a .fla or the Flash IDE.

   This is a huge win for achieving full open-source status for the flensed projects! Going forward, all other flensed project SWF assets will endeavor to adhere to this same method. Also, the great news is that the SWF files (in general) end up either smaller or more efficient (or both!) in execution as compared to the Flash IDE compiled versions.

5. JS assets are now compressed and highly optimized: As alluded to earlier in this post, the .js files in the flensed projects have all been run through (and tested from!) the latest YUI Compressor technology. All in all, when factoring in all assets for the entire set of flensed projects, the total optimized compressed weight (before gzip server-delivery compression) is under 47k! Of course, all fully expanded, commented source code is available with the release as well, but the Javascript assets are now fully ready for optimized production usage.
6. Increased cooperation with major JS Frameworks: Over the last few months, I’ve been working on improved integration of flXHR into two major JS Frameworks, Dojo and jQuery. Dojo has come out with the ‘XHR Plugins Repository’ which allows multiple XHR-like transport mechanisms (like flXHR, IFRAME-proxies, dynamic-script-tags, etc) to register themselves with the framework and then calling code can automatically have the appropriate transport mechanism selected and used for it when it requests an Ajax request. jQuery has a similar feature called the “XHR Registry”.

   The flXHR demos page already had simple proof-of-concept ways to integrate flXHR with both these frameworks. The exciting thing that these Registry/Repository features brings to integration is officially supported and condoned adaptation, rather than end-around hacking. To that end, I’ve been working on getting an official “plugin” of flXHR for both Dojo and jQuery. The authors at Dojo have been communicating and working with me to get a flXHR plugin approved to be included with DojoX. I have a similar effort going with jQuery as well. The end result is that flXHR will achieve one of its primary goals — namely, that it is easily dropped in and used with any major JS framework with little to no effort on the part of authors.

That’s it for now. There’s obviously more effort going on than just this, but those are the major points to be aware of at the moment. Let us know if you have any thoughts on the direction we’ve gone with this release, or suggestions for future improvements or functionality.