the Fresh!

CheckPlayer v0.6-alpha6 v0.6-alpha5 v0.6-alpha4 v0.6-alpha3 has been released, which fixes all the known bugs *except for one new one, related to plugin updating in FF3*, and adds a couple of minor new features.

1. The “flensed_base_path” parameter now no longer needs to be specified, as it is auto-detected from the loading of the script itself. However, you can still use it, and may need to if it’s being used in a strange environment like inside a CMS with weird path issues or whatever.
2. DoSWF() now supports an extension to the “targetElem” (formerlly labeled “replaceElemIdStr”) parameter, which allows an author more control over how the SWF is added to the DOM. The default “replace” behavior (as SWFObject’s embedSWF() does) is maintained. However, an object can alternatively be passed for this parameter, with a named key property of either “replaceId” (same behavior) or “appendToId”, which mimics more the SWFObject 1.5 behavior, which is that it will append the SWF as a child of the targetElem. Also, a value of null or false can be passed for this parameter, which simply adds the SWF to the end of the BODY (essentially the same as passing appendToId:bodyId). The goal is to give the author more flexibility in SWF authoring. Note: Existing code will work the same as before and doesn’t need to be changed.
3. Numerous minor bug fixes (and regression bugs) were addressed in this release. This should be the most stable CheckPlayer release so far.

I strongly encourage everyone to upgrade to this new release of CheckPlayer for optimum performance.

I’ve put up two new demos…

1. Demo #11 (a, b, and c) is a demo showing integration with jQuery… it uses a patched version of jQuery 1.2.6 which I was able to convince the jQuery dev team to make. Hopefully the next release of jQuery will include the patch so everyone can share in the joy that is flXHR. It operates under the same premise as the other framework integration demos.

2. Demo #12 is an interesting demo… it shows actually a more brute force way of adapting flXHR into a page. It literally overwrites the native XHR object (and for IE, the ActiveXObject instantiator) and forces a flXHR instance to be returned instead.

This is useful for any scenario where there’s no way to adapt a set of code to use a different XHR, but you still want to use flXHR. For instance, the DWR framework has a similar restriction to what jQuery (without the patch) has, which is that it exposes no way to override the transport creation.

Ajaxian.com is an incredibly well read site with tons of amazing articles about anything Javascript and AJAX related. I’ve read the site for a long time now. Dion Almaer just put up a great brief article highlighting the flXHR project! Go check it out, and while you’re there, check out all the other great content that Ajaxian.com has to offer.