Yar. jQuery was actually the model I was thinking about when this question first came up. It's very helpful.
V On Thu, Jun 11, 2009 at 2:23 PM, Getify Solutions, Inc. <[email protected]>wrote: > maybe we need a "noConflict" mechanism like jQuery... it makes that sort > of thing SO easy. that's an intriguing idea to consider for the future. > > --Kyle > > > > > *From:* Vincent Polite <[email protected]> > *Sent:* Thursday, June 11, 2009 4:13 PM > *To:* [email protected] > *Subject:* Re: Using SWFObject in a corporate project > > I pretty much agree with you. The question becomes a little more > interesting if you are looking at different versions of SWFObject on the > same page, which is entirely possible (this is a common thing in certain ad > distributions where you include both the reference javascript and code in a > snippet). I guess that leads me to possibly advocate making sure not only > is SWFObject in use, but the correct version is in use for certain calls; > having a wrapper class (or having that built in to core swfobject) might > make me feel warm and fuzzy only from the standpoint that you would be able > to quickly tell via a debug log statement or some other response whether or > not you were actually running into that situation where the object you > expected to be able to use is being overwritten/redefined by a new .js load. > > The undefined check is probably good enough to run with for now. I'm a big > fan of at least being able to query the object for versioning information as > well, though; presuming it's easy enough to add if it's not there already. > > Vincent > > On Thu, Jun 11, 2009 at 12:06 PM, Getify Solutions, Inc. <[email protected] > > wrote: > >> I don't think there needs to be multiple namespaced versions of the >> swfobject "object" floating around in a DOM. >> >> As is, the multiple inclusion WILL overwrite each other each time, which >> would have the unfortunate behavior of possibly causing some previously made >> calls against the swofbject api to not finish as expected. >> >> However, wrapping the entire swfobject definition in a simple if-statement >> would fix that problem. Then, no matter how many times it's included, >> everyone will be calling the same global singleton swfobject instance. It's >> more than capable of brokering calls from various different places. >> Interally it manages "state" before DOM load when it queues up calls from >> embedSWF or registerObject, and then keeps SWF refs around for IE cleanup >> purposes. >> >> Our core library distribution doesn't have this if-statement logic wrapped >> around it, and arguably maybe it should. But it should be an easy change for >> you to make (assuming you at least can change which copy of swfobject all >> those different places are calling). >> >> Something like: >> >> if (typeof window.swfobject != "undefined") { >> swfobject = function(......... >> .... >> ... >> } >> >> --Kyle >> >> >> >> >> >> >> *From:* Vincent Polite <[email protected]> >> *Sent:* Thursday, June 11, 2009 1:33 PM >> *To:* [email protected] >> *Subject:* Re: Using SWFObject in a corporate project >> >> Version control and namespace over an open source library is definitely an >> interesting topic. :) >> >> From an SWFObject standpoint, the question becomes one of whether or not >> it is desirable for the SWFObject "object" exist as a true singleton or if >> there is a need for having several instances of SWFObject to exist (even if >> the version numbers are the same). >> >> The only way that you could make sure that YOUR code always works >> regardless of what is going on around you is by giving your SWFObject a >> unique namespace and coding around that namespace. You could achieve that >> by hacking the SWFObject code that you are using or adding some sort of >> helper routine. >> >> I think SWFObject being "aware" of other SWFObjects on a page and even >> having an SWFObjectManager class isn't a horrible idea either, but these are >> just random musings. >> >> Because of the potential for overwrite, I guess the actual solution would >> require modification to the existing code library; making sure that the >> SWFObject has an identification that is undeniably unique for your >> application usage. Whether you want to do that by adding some unique GUID >> routines or some other means would be up to you. >> >> One method that might occur to me would be something like pseudo-coding: >> >> if SWFObject.getUniqueId is defined, then generate getUniqueId which >> returns the string of the unique identifier of the SWFObject that will be >> used by this class. The actual ID couldbe generated with a combination of >> random numbers, datetimestamp, and version number of SWFObject ( I would >> prefer creating some regular pattern/id so that it could be reverse >> engineered that a given SWFObjectId must have come from version x.x). The >> actual generator routine might be something like: >> >> generaterandomid >> eval("generaterandomid = new SWFObject()") >> >> which would create a reference that you could then use globally. >> >> Just thoughts my caffeine addled brain is working with atm. Not sure if >> this helps. >> >> Vincent >> >> On Thu, Jun 11, 2009 at 11:04 AM, Bertrand <[email protected]>wrote: >> >>> >>> Hi, >>> >>> First, I would like to thank Bobby and the whole team for the recent >>> release of SWFObject 2.2. You guys are doing a great job coding, >>> supporting, evangelizing and helping developers around the world. For >>> that, a warm and sincere THANK YOU. >>> >>> So here's my question: >>> >>> I've introduced SWFObject in the project that my development team is >>> about to release in a few days and there's a problem I can't wrap my >>> head around: >>> >>> What happens when several entities are trying to make use of SWFObject >>> on the same page, each one of them including the swfobject.js in the >>> head of the document and not caring about the others (my company >>> serves ads on webpages). I figure libraries could clash with each >>> other, especially with different people using different versions of >>> the library. I just want to know how I could make sure to have the >>> version that I need available without causing any problem (find some >>> insulation/sandboxing/wrapping mechanism). >>> >>> Cause everything's fine when you have control over the page the >>> library will be used on, but it's not my case :) >>> >>> Thanks a lot. >>> >>> I can rephrase if that post doesn't make sense, English is not my >>> native language. >>> >>> >> >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SWFObject" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/swfobject?hl=en -~----------~----~----~----~------~----~------~--~---
