registering objects should be possible using a class name instead of an ID as an alternative

[GoogleCodeExporter]

My suggestion would be to add an additional method to the swfobject object,
called e.g. 'registerObjectsByClassName', that could be called instead / in
addition to the 'registerObject' method, like this:

<script type="text/javascript">
    swfobject.registerObject("my_class", "9.0.0",
"expressInstall.swf");</script>

this would add the class name 'my_class' to a new array, say 'regClsArr',
which would then be processed by the 'main' method, which would add all ids
of the document elements that have one of the classes listed in 'regClsArr'
to 'regObjArr' before this is processed.

This would allow plugins or frameworks which build pages using swobject
dynamically to add the JavaScript to register Flash objects to the head
section without knowing beforehand which object tags with which ids are
inserted into the page body later.

For an example of the implementation of a function to get elements by class
name, see MochiKit's 'getElementsByTagOrClassName' at
http://svn.mochikit.com/mochikit/trunk/MochiKit/DOM.js.

Original issue reported on code.google.com by Spotligh...@gmail.com on 30 Sep 2008 at 7:35

[GoogleCodeExporter]

Well, conceptually that makes no sense at all.

Ids are used for unique HTML elements, while with class you are able to target
multiple elements. And SWFObject only deals with unique instances: 1 piece of
alternative content (HTML element) maps to 1 SWF (HTML object element).

Original comment by bobbyvandersluis on 4 Oct 2008 at 9:52

• Changed state: Invalid

[GoogleCodeExporter]

I think I wasn't clear enough about how this is supposed to work: The class name
would only be used by the main function too find all elements which have this 
class
name. These objects would then be added to regAttrObj, like the the objeccts 
that
have been added with register_object(). Basically this is like doing
register_object() for all objects that have a ceraatin class name but without 
the
need to know the ids of these objects (they don't even necessarily need to have 
one).

Original comment by Spotligh...@gmail.com on 4 Oct 2008 at 10:03

[GoogleCodeExporter]

Ok, static publishing only, I get it :-) I will add it to the enhancement list. 

Original comment by bobbyvandersluis on 4 Oct 2008 at 10:31

• Changed state: OnHold

[GoogleCodeExporter]

Original comment by bobbyvandersluis on 4 Oct 2008 at 10:31

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Is there any progress on this?

I need this for a WordPress plugin, since there's no easy access to the content 
of the posts on a given 
WordPress page at the time of creation of the page header.

That is, it would be much easier if SWFObject could just find all flash objects 
with a given classname on its 
own instead of me looping through all WordPress posts, extracting ids, 
registering them with SWFObject when 
the header of the page is created only to loop through all posts again later 
on. 

The easy solution is to give each static flash object an ID, loop through every 
object, check the classname, get 
the ID and register it with SWFObject, but ideally SWFObject shouldn't need an 
ID at all, just a DOM-node.
Is there any potential danger of just sticking DOM-nodes into regObjArr instead 
of ids?

Original comment by b...@benderydt.com on 8 Dec 2008 at 4:22

[GoogleCodeExporter]

Although I sincerely like the idea of this method, it didn't make the selection 
of
SWFObject 2.2 alpha, and to be honest, I don't think we will include this in the
future either. The main reason for this decision is that we have agreed to keep 
the
minimized version of SWFObject under 10Kb and that this feature would cost us at
least an additional Kb, while it is a feature that is only requested by a few 
and
priority-wise at the bottom of the requested features list.

Original comment by bobbyvandersluis on 5 Jan 2009 at 4:47

• Changed state: WontFix

[GoogleCodeExporter]

Would you be interested in an experimental patch which tries to get rid of ID's 
in swfObject as much as possible? 
I.e. refactor the internal code so it works on DOM nodes instead? I could try 
to knock something together next 
week, but only if has a slight chance at success. So please stop me before I 
jump into the abyss...

Original comment by b...@benderydt.com on 13 Jan 2009 at 11:32

[GoogleCodeExporter]

We are always interested in new ideas, especially if they are good, and if we 
can do
things in a smarter way, we will. However I can tell you beforehand that we are
unlikely to change the current SWFObject API. We will also unlikely add 
features that
require a lot of additional code and only will be used by a few. Also, please 
keep in
mind that in IE the HTML object element (and its nested elements) is only 
partially
implemented in the DOM, so you have to keep in mind additional built-in 
behavior and
accessibility issues. 

Original comment by bobbyvandersluis on 14 Jan 2009 at 10:08

[GoogleCodeExporter]

Basically I'd like to replace createSWF and removeSWF by createSWFNode and 
removeSWFNode and let the old 
createSWF and removeSWF functions call the new one after their initial 
getElementById. Since both functions 
start with getElementById I see no immediate trouble (famous last words), aside 
from the fact that createSWF 
stores ID's in objIdArray for cleanup. I will have to change this to an array 
of references to nodes. Do you see 
any trouble in that?

I'll also have to change some calls of setVisibility to setVisibilityNode. 
(Same system, aside from the dynamic 
CSS trick).

I know that I'm assuming that any calls to createSWFNode, removeSWFNode and 
setVisibilityNode happen after 
the dom is loaded, but a) embedSWF, the major defined API, takes care of that 
and b) the documentation for 
createSWF uses it in an onDomLoad event handler and c) I can't see the point of 
removeSWF before the DOM 
has loaded...

Original comment by b...@benderydt.com on 14 Jan 2009 at 8:19