Possible Blocker on Issue 406

[Bryan Kyle]

Hi All

I have a fix ready for issue 406, but I'm blocked on what I believe is the need for a rollup of the ubiquity-backplane library.

I've modified xlink.js to use a schemeHandler if one is available for the GET operation of actuating the link.  In doing this I've added ubiquity-backplane as a required module for libxh-xlink (the module for xlink.js).  This appears to have the desired effect of ensuring that ubiquity-backplane is loaded before libxh-xlink.

To test this change I've created a simple for that contains an xf:instance element with an @src referencing a local file.  When I went to test the I was receiving a failure when referencing into schemeHandlers, meaning that it hasn't been created yet.  Looking through the scripts loaded in the head element confirmed that.  So for some reason the decorator appeared to be running before all of the required modules had been loaded.  Searching further I was able to determine that the decorator was running from the inclusion of second-onload.js which includes adds a CSS that calls the decorator.

After thinking about this for a while I have a hypothesis for the behaviour I'm seeing.  I believe that the ubiquity-backplane loader is being included, which means that the dependency is satisfied, but that loader hasn't included all of its scripts before second-onload is included.  In essence, I believe this boils down to a difference of opinion on what "included" means.  I interpret included as "the module and its dependencies are present" while YUILoader interprets this as "the markup to include the module has been written to the document and the browser will load it sometime later."

Does this make any sense or am I out to lunch?

Given that I don't have access to the ubiquity-backplane library I'm wondering if someone could either create a rollup for ubiquity-backplane or grant me access to the module so that I can create the rollup myself.

Thanks

--
Bryan
http://bryan-kyle.blogspot.com