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

Reply via email to