I pushed a few tweaks to https://github.com/amb26/videoPlayer/tree/demo-integration-sketch to show that
videoPlayer can be instantiated as late as you like in the page lifetime using the existing
"fluid.videoPlayer.makeEnhancedInstances" method and still work fine. This exposed a logic error in the
existing implementation which didn't seem to be having any effect... It seems that the "setTimeout" which is
part of the "lateListener" in this method which is there to work around FLUID-4192 is also succeeding in
delaying instantiation sufficiently so that we always ended up later than UIOptions in any case.
Right now the "Mammals" demo in the branch delays the instantiation of the 3rd video player on the page for
a full 5 seconds to show that this same method can work at any point in the page cycle. In fact, the only
danger is in initialising videoPlayers too EARLY, not too late. Fixing the negation of the condition on line
221 in VideoPlayer_uiOptions.js should now reliably ensure that we never create a videoPlayer too early, no
matter how long it takes UIOptions to load its templates. This kind of race condition will be pretty hard to
write a test case for but I guess we should make an attempt when we have more time.
Cheers,
Antranig.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
