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 -~----------~----~----~----~------~----~------~--~---
