the Fresh!

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.

The flensedCore, CheckPlayer, and flXHR projects have all undergone significant reworkings to address various bugs and improve performance and functionality. They have been consolidated together into a 1.0 release candidate, available here. This release is considered stable, but not production ready yet (though it’s very close!). Please test it at your convenience and give any feedback you may have before we declare a full production 1.0 release.