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