the Fresh!

Update: Upon further discussion with some jQuery devs, I’ve decided my hard stance was over-reactionary and that further discussion with them is warranted and appropriate. Please take the rest of this post and comments with a grain of salt, and my apologies for any ill-will it may have caused. For my part, I will be exploring (and assisting them in finding) ways that jQuery can be improved which satisfy all involved (including hopefully to the benefit of flXHR and our community).

I learned some saddening news just now, related to close-mindedness on the part of the jQuery devs. I filed this ticket on behalf of our project and our community a week or two ago:

http://dev.jquery.com/ticket/3087

The problem is that jQuery’s architecture makes it difficult (but not impossible, see http://flxhr.flensed.com/demo.php#demo12) to adapt in a replacement for XHR. Many of the other major frameworks provide a way to do this, meaning they recognize the need to play well with others. At first, things seemed promising. The fix turned out to be a really simple one, like 5 simple lines of code, and this patch was provided:

http://dev.jquery.com/attachment/ticket/3087/ajax_transport.diff

I then followed up by asking if that patch would make it into a jQuery release. As you can see by the final comments on that ticket 3087, the jQuery devs have decided that flXHR and its effort to provide an XHR replacement is too narrow and is irrelevant since it’s only for “one user”. I know that’s not the case, because I know there are hundreds of you out there using flXHR already, and I’m sure some of you are trying to make it work in a jQuery environment. For what it’s worth, until this debacle, jQuery was my library of choice. This changes my whole opinion. I guess they’re so busy they just can’t be bothered with 5 simple lines of code patch.

As I mention above, the good news is that there’s still a workaround, though not as graceful as hoped, as illustrated with demo #12. Basically, this is the catch-all example for how *any* page or set of code can be changed to use flXHR, without the existing code even knowing it, by simply using the dynamic nature of the Javascript language and overwriting the native XHR object with flXHR. It’s actually really quite simple, but it’s a little more “heavy-handed” and brute-force in nature. But there are some libraries and code where this will be the only choice (like jQuery!), so there ya go.

Anyway, I was hoping maybe to stir up some sentiment from anyone here reading this blog to perhaps feel like they could make a counter-statement on that closed ticket, just so jQuery devs know that it’s indeed not just “one user” they so casually dismissed. You have to have a jQuery dev account to comment, but it’s easy to sign up here: http://dev.jquery.com/register

I’m sure this won’t really make a difference in their mind. But on principle alone, I think their poor social skills are something that should at least be called out and kept to task. [I would like to retract this previous statement, as it's come across as mean and that was not my intent.] And maybe it’ll help them re-consider in the future when other projects are hoping to coordinate with their framework.

Found another couple of sites that mention short blurbs about flXHR. Also, SWIK picked up on flXHR through del.icio.us association with AJAX, SWF, and Opensource. The word is spreading, slowly but surely!

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.