bobby, i your investigation is very interesting. the new approach sounds more reliable RE: version numbers, but as you said, waiting for DOM to be ready changes the flow. personally, i don't think waiting for the domready is a bad thing, as we have to wait for domready for any embed to happen anyway (for dynamic publishing). javascript doesn't manipulate the DOM until domready anyway, right?
if it means more rock-solid detection, i say waiting for domready is a fine trade-off. kyle, your proposal (doing both types of version detection) is logical and thorough, but also adds a lot of overhead. i imagine most people would prefer to use just one method, as it executes faster and reduces swfobject.js file size. maybe you can add it to your flensed project as a swfobject add-on? - philip On Thu, Oct 30, 2008 at 10:11 AM, Getify Solutions <[EMAIL PROTECTED]> wrote: > > Yeah, Bobby, I read that update earlier today, actually. I like the > direction you're going with it. My thoughts (which I'm going to add to > that > post as well) are: > > 1. in regards to the "gap" of having to wait for the DOM to load to do the > version checking, maybe we should have both detection methods (existing one > before DOM ready, new one after DOM ready). Only if they disagree, then it > can complain (or initiate ExpressInstall, etc), otherwise it can go forward > with the embed as normal. This should also help with multiple installed > versions, right, as the second one is always going to use the newest > plugin, > it would seem. > > 2. #1 above seems like it might work for dynamic embedding, but I'm unclear > as to how it might work with or affect static embedding. Perhaps the same > logic applies, but maybe it needs different thinking. > > 3. The "delay" in processing of logic may require some re-working of how > and > when swfobject does its magic. For instance, we might want to go ahead an > embed a SWF as soon as possible, and get it to start loading, but maybe not > display it until both version checks have passed. In this way, we could do > version detection both before DOM ready *and* after DOM ready, but *not* > actually prevent an embed (force EI) until after both version checks have > occurred. So to the calling code, it proceeds as normal, and the decision > to > swap to call removeSWF() on the already loaded SWF and instead swap in EI > could be done transparently to both the user and the calling code. > Combined > with the visibility thing I just mentioned, this could keep the transition > still pretty seamless for users, with the side effect being that some extra > (possibly unnecessary) SWF downloading had to occur. > > 4. Or, perhaps, to prevent so much impact on that existing logic flow, we > could instead have users of swfobject be able to register a callback > function to be notified if version conflicts are found. That way the > author > can respond appropriately (calling removeSWF(), hiding, retrying to > initiate > EI, etc) if their code is notified that a version mismatch has later been > detected. > > > > --Kyle > > > -------------------------------------------------- > From: "Bobby" <[EMAIL PROTECTED]> > Sent: Thursday, October 30, 2008 11:44 AM > To: "SWFObject" <[email protected]> > Subject: Re: New tutorial for full-screen flash with browser scrollbars > > > > > Thanks Kyle, I've added it to the links page on the wiki: > > http://code.google.com/p/swfobject/wiki/links > > > > Unrelated, but I think that you'll find the following interesting: > > http://code.google.com/p/swfobject/issues/detail?id=155#c7 > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
