Well, getting the reference of the object would be up to the programmer, of course. The same way it's his responsibility to get the IDs. I personally never execute stuff before the page gets ready, except for my addEvent function. And that's the general direction most frameworks today do stuff too. As I've already said, such functionality would make certain scenarios much better to handle.
Perrin4869. On Aug 31, 7:00 pm, Vincent Polite <[email protected]> wrote: > That would be an excellent reason why you couldn't do it willy nilly. > > Vincent > > On Mon, Aug 31, 2009 at 8:36 AM, Getify Solutions, Inc. > <[email protected]>wrote: > > > Forgive me for jumping in late (and I admit I've not read this whole > > thread), but the standard use of registerObject() is in the case where the > > call is made in the HEAD of the document, before such a DOM element would > > even exist. So, this proposed change seems a cart-before-the-horse scenario, > > where race conditions could likely occur. > > > AFAIK, SWFObject queues up the processing of the registerObject() calls > > until DOMready, so theoretically, all objects should be available to it at > > that time. But, a reference made to a non-existent (at the time) DOM element > > would not necessarily (depending on how it was made) be now a valid > > reference to said object. This to me is a question of "when" the resolution > > of id-to-object happens... and the question is, does that happen BEFORE > > domready, or AFTER it. If I am correct in that assertion, I think it's quite > > problematic to suggest that we support in any way shape or form dealing with > > DOM object references BEFORE domready, as this will lead to nightmares in > > cross-browser testing and support. > > > Just my 2 cents. > > > --Kyle > > > *From:* Vincent Polite <[email protected]> > > *Sent:* Monday, August 31, 2009 10:24 AM > > *To:* [email protected] > > *Subject:* Re: IDs on object tags > > > That does seem to be all he's asking for. > > > As I understand it, Javascript Objects passed into functions are by default > > passed by reference. So any manipulation of the DOM provided that it occurs > > outside of simple primitive argument passing, will be done by reference. If > > all he is asking for is an alternative register/constructor that takes as an > > argument an actual object reference to the DOM node instead of the id, then > > that would seem simple enough to address presuming that the underlying > > swfobject code handles management of its DOM nodes similarly. > > > It will save N cycles in parsing a DOM object (saving redundant lookup > > queries) and clean up his javascript processing code. > > > It will not clean up his markup, though. The reason that the markup in > > static Publishing is so messy is because of the desire to fulfill standards > > compliant markup and have functionality in the event JS is unavailable (in > > which case, any notion of DOM manipulation falls apart). > > > Whether or not the idea behind this alternative constructor could be used > > to make swfObject itself more efficient would depend on how DOM elements are > > handled within SWFObject. But, you would definitely save processing cycles > > if such a method existed. > > > While I would not advocate removing a byID reference, adding the ability to > > pass in a DOM element seems reasonable, although it does allow one to > > backdoor their way into non-compliant markup by providing a way around the > > "multiple DOM elements with the same ID" rule. > > > Vincent > > > On Mon, Aug 31, 2009 at 8:06 AM, Philip Hutchison > > <[email protected]>wrote: > > >> ok, so let me see if i can describe the situation in simple terms: > > >> you're saying you have multiple static <object>s on the page, and you'd > >> like to be able to apply swfobject.register to each of them without giving > >> them IDs. > > >> you argue that if you were allowed to pass the HTML element in place of > >> the ID, you could simply loop through the <object>s on the page and apply > >> registerObject by passing the element itself. > > >> swfobject.registerObject(*id*, swfVersionStr, xiSwfUrlStr, callbackFn) > > >> becomes > > >> swfobject.registerObject(*id or element*, swfVersionStr, xiSwfUrlStr, > >> callbackFn) > > >> is this correct? > > >> - philip > > >> On Mon, Aug 31, 2009 at 2:36 AM, Perrin4869 > >> <[email protected]>wrote: > > >>> Hello Vincent, philip: > > >>> @philip: sorry, the div tag was a mistake of mine, I actually meant > >>> object tags, the same way as the example on SWFObject's object. I am > >>> using static publishing (out of preference). > > >>> @Vincent: Well, in the very end, you can always generate IDs, have > >>> your objects iterated by class, and registering by the generated ID, > >>> but why insert unnecessary markup? > >>> In my opinion retaining a reference to the DOM object itself is better > >>> than retaining IDs because that way you have direct access to the > >>> object, rather than just an ID. > >>> I think overall the object reference is a better solution for 2 > >>> reasons: > >>> 1) Systems with independent components will benefit of having a simple > >>> way to embed Flash. After all, having each component generate an ID > >>> can cause trouble. For example, what if 2 instances of the component > >>> are embedded at the same time? > >>> 2) In the end, each getElementById is a query, and takes time to > >>> execute. Why not keep a reference to the DOM object? In the end it's > >>> just a reference, it's not like we're wasting memory here. > > >>> In short, systems in which it's uncertain when or where or how Flash > >>> elements are embedded would benefit most from such functionality, in > >>> my opinion. > > >>> Thanks for getting back at me, I'll be awaiting your response, > >>> Perrin4869. > > >>> On Aug 31, 5:15 am, philip <[email protected]> wrote: > >>> > oops, link in last post should have beenhttp:// > >>> code.google.com/p/swfobject/wiki/api#swfobject.embedSWF%28swfU... > > >>> > On Aug 30, 7:13 pm, philip <[email protected]> wrote: > > >>> > > hi perrin > > >>> > > you mention you want to embed a SWF in every <div class="flash">. > >>> your > >>> > > example illustrates that you want to embed the same SWF for every > >>> <div > >>> > > class="flash">. this can be accomplished by using embedSWF in a > >>> custom > >>> > > function. > > >>> > > seehttp:// > >>> code.google.com/p/swfobject/wiki/api#swfobject.createSWF%28att... > > >>> > > you could do something like: > > >>> > > var flashElements = getElementsByClassName("flash"); > >>> > > var flashElementsCount = flashElements.length; > >>> > > var flashvars = {}; > >>> > > var params = {}; > >>> > > var attributes = {}; > > >>> > > for(var i = 0; i < flashElementsCount; i++){ > >>> > > var id = "swf_" +i; > >>> > > flashElements[i].id = id; > >>> > > swfobject.embedSWF("mymovie.swf", id, "550", "400", > >>> > > "9.0.0","expressInstall.swf", flashvars, params, attributes); > > >>> > > } > > >>> > > (of course there are a gazillion ways to refactor this code, but you > >>> > > should get my point) > > >>> > > in your examples you always mention swfobject.registerSWF; this is > >>> > > only to be used for *static* publishing (dynamic publishing already > >>> > > handles this chore). i don't understand why you're using registerSWF > >>> > > if you're adding SWFs dynamically. > > >>> > > - philip > > >>> > > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
