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