Funny you mention that because a friend of mine came up with the exact same solution yesterday. Using an anonymous closure around the whole code to make sure that no namespace pollution can happen. It's totally possible since swfobject is defined as a variable, which is then scoped to the aforementioned anonymous wrapper function. So in the end, good job you guys, you made it easy for me.
Thanks a lot. On Jun 11, 3:09 pm, "Getify Solutions, Inc." <[email protected]> wrote: > If it helps, the swfobject code could easily be patched to do something like > that: > > (function(_swfobject){ // add this line to the top of swfobject.js > > // main swfobject decl, don't touch > var swfobject = function(....... > ...... > .....; > // end main swfobject decl > > // add the following few lines to the bottom of swfobject.js > window.swfobject.noConflict = function() { > window.swfobject = _swfobject; > return swfobject; > }; > > window.swfobject = swfobject; // make our self public > > })(swfobject); > > --------------------------------------- > > Now, you use this in your own code by calling it like this: > > var swfobj22 = swfobject.noConflict(); > > swfobject.embedSWF(...); // swfobject is some other version, like v2.1 or > whatever > > swfobj22.embedSWF(...); // swfobj22 is v2.2, so it has the new functionality > in it. > > So you're code can use swfobj22 and the rest of the legacy uncontrolled code > continues to use swfobject 2.1 (or whatever) by calling the regular old > "swfobject" reference. > > --Kyle > > From: Vincent Polite > Sent: Thursday, June 11, 2009 4:47 PM > To: [email protected] > Subject: Re: Using SWFObject in a corporate project > > 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 > 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 > 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 -~----------~----~----~----~------~----~------~--~---
