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

Reply via email to