Just to jump in. I think that it is a reasonable thing to iterate over existing DOM elements using something like a class name to automate the registration process. Many JS frameworks like jQuery make a living at having developers define groups of elements using a class (which can be linked to one or many DOM objects without issue), and then iterating over the collection of elements that satisfy that condition.
Quite literally, you could just define individual objects simply with a class = "embedswf" and then have a function just handle the automated registration. Doing cute things like defining attributes that correspond to the various flashvars would be fairly trivial as well. This would seem to be functional as long as you were embedding your intended content somehow in the Dom object via attributes or hrefs or somesuch. Once the embed is complete, however, unless you are committing to retain a reference to the DOM object itself, it seems that an ID would be the cleanest way to get a reference to such an object after the fact. Specifically, if you wanted to perform some operations on the DOM elements after the fact, how would you pick and choose without an ID. So if your goal is to just automate a ton of .swf files, then I definitely see the utility in what you are proposing, but it would seem to me that would not want to "lose" the ID outright as a reference. Adding equivalent methods to SWFObject that reference and reverse-reference actual DOM objects might be something worthwhile, but I would be curious about the specific use cases that would justify adding those methods to what is, as I understand it, a fairly lean bit of javascript. I tend to always use the dynamic method of invoking SWFObject, so because of that, I'm OK with javascript being available, etc. My understanding though is that using the static publishing method has double redundancies in play so that if javascript is somehow not enabled, that you still have the object embeds to actually embed the flash objects. I could totally be wrong about that, and because I am starving and smell some BBQ steaks on the grill, I'm going to stop here. FWIW, I deal with a variable # of flash elements in a project I am working on. The way I deal with it is I create a javascript object called SWFObjectmanager. I register my flash embeds dynamically, and it handles some of the housekeeping like verifying whether or not the Flash movie has loaded yet, and if it hasn't keeping track of any state information that I think is important. Not sure if this makes sense, but at a fundamental level, I still use an ID, albeit a generated one. Best, Vincent Polite Apologies if you've said it already, but what is your specific use case where you feel you need this degree of efficiency and lack of reliance on the Dom ID? On Aug 27, 2:29 am, Perrin4869 <[email protected]> wrote: > Well, document.getElementById(id); is just an example, you can easily > get dom elements with functions like > document.getElementsByName(name) or a custom getElementsByClassName > (className) fuunction, > and iterate them, registering them to swfobject. > Your method is what I've been using up until now, but it has > shortcomings. First, I must take care of both markup and scripts, > instead of automatizing. > Second of all, the 10 there is an arbitrary number, in a real code I'd > need to figure out what the count is myself. > > Let's say I created a file upload control in PHP, and someone uploaded > Flash content with it. Now, my file upload control also has the > capability of previewing which content > it has saved before, and also if it's Flash, it can embed it for a > preview. But, I don't know the number of upload controls, and I also > don't know the upload controls that have > Flash saved in the database, and having them register some header > content is not really a possibility. Now, if I could just give those > elements a class name or something > to go by which can be easily queried, the problem would be solved by > querying those elements, and registering them through an iteration, > like in my example in the first post. > > var flashElements = getElementsByClassName("flash"); > var flashElementsCount = flashElements.length; > var i; > for(i = 0; i < flashElementsCount; i++) > { > swfobject.registerObject(flashElements[i], "9.0.0"); > > } > > I hope I made what I am trying to accomplish clear. I mean, having to > give an ID to each object is just a pain, and it doesn't really have a > clear advantage, sometimes you > just want to create a collection of Flashes for any reason, and > register them by iterating, and if their count is variable then you > have to take care of figuring it out, ending > with lower performance code. > > Thanks for the attention! > Perrin4869 > > On Aug 27, 6:09 am, Aran Rhee <[email protected]> wrote: > > > RE: using document.getElementById("") - Right, but you just said you didn't > > want to create any id's, so hopw are you going to use that method? > > > So the way I see it is that your problem can be broken down into two parts: > > > 1) creating the required page elements > > 2) calling swfobject methods > > > In regards to 1), if you use a server-side language, or something like > > jQuery to generate your static publish blocks, then you can have a class > > (for styling / positional purposes) and a id naming convesion put in place > > really easily. How were/are you creating all of your <object> blocks anyway? > > > Then for 2) in calling registerObject(), you can just pass your common > > naming convension + counter in a loop like your example code. > > > // simplified example > > for(i = 0; i < 10; i++) > > { > > swfobject.registerObject("swf_file" + i , "9.0.0"); > > > } > > > Aran > > > On Thu, Aug 27, 2009 at 11:47 AM, Perrin4869 > > <[email protected]>wrote: > > > > Sorry for the typo on my post above, in the first line I meant passing > > > a DOM Element, > > > like the ones you get by document.getElementById("");. > > > > On Aug 27, 4:01 am, Perrin4869 <[email protected]> wrote: > > > > Well, doesn't passing a DOM give you total control over the individual > > > > element/swf? > > > > And if it doesn't, can't SWFObject generate the ID for the object > > > > automatically? Leaving it up to each element to define it is not > > > > practical at all, leaving the possibility of duplicates, for example. > > > > > The whole idea is that if a list of swf files get embedded, and > > > > there's a variable number of them, you can just register them by a > > > > common denominator, like a class or name. > > > > > And editing SWFObject isn't a very attractive solutions because of two > > > > reasons: > > > > 1) I would have to take the enormous task of learning how it works. > > > > 2) I would have to make changes for each future release. > > > > > Thanks for the support! > > > > Perrin4869 > > > > > On Aug 27, 3:40 am, Aran Rhee <[email protected]> wrote: > > > > > > Well, a class is not unique, so how were you thinking to target an > > > > > individual element / swf on the page? We need a unique DOM id for > > > > > doing > > > > > things like ExternalInterface calls to/from the swf file, and being > > > able to > > > > > target removing alternate content etc. > > > > > > Also how is it that ids cannot be fully trusted? The whole DOM thing > > > kinda > > > > > relies on the fact that it does work :) > > > > > > RE: Generating id's / elements: > > > > > > // client side > > > > > var div = jQuery('<div>Some text</div>').addClass('foo').attr('id', > > > 'bar'); > > > > > div.appendTo(document.body); > > > > > > // or use a serverside language like php. > > > > > > it is really not very hard... > > > > > > SWFObject is open source, so if you feel you want to make a mod to > > > > > suit > > > your > > > > > own needs. > > > > > > Aran > > > > > > On Thu, Aug 27, 2009 at 10:00 AM, Perrin4869 <[email protected] > > > >wrote: > > > > > > > Hello, I've been using SWFObject for my Flash embedding needs. > > > > > > Now, I think that the registering method is a bit flawed. If I > > > > > > wanted > > > > > > to automatize the registering process, or even register dynamically > > > > > > generated items, having to pass an ID is disadvantageous. Generating > > > > > > an ID for each element is a tedious work, and you can never fully > > > > > > trust it. > > > > > > > Now, what I'd like to accomplish is to register the flash elements > > > > > > based on a class given to them. I'd like to do something like this: > > > > > > > var flashElements = document.getElementsByClassName("flash"); > > > > > > var flashElementsCount = flashElements.length; > > > > > > var i; > > > > > > for(i = 0; i < flashElementsCount; i++) > > > > > > { > > > > > > swfobject.registerObject(flashElements[i], "9.0.0"); > > > > > > } > > > > > > > Is there a way with the current version of SWFObject to accomplish > > > > > > what I'm trying to achieve? If not, what are the chances of getting > > > > > > support for it in subsequent versions? > > > > > > > Thanks for the help! > > > > > > Perrin4869. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
