During the development of the new Gaia Online layout, one of the most challenging things was the dependancy on two separate servers. In the case of Gaia, all images, CSS, and JS are served from the graphics.gaiaonline.com domain, while PHP and HTML and processed on the www side. This wouldn't have been much of a problem if the inline calls to the JavaScript weren't beating the loading of the JS from the header. In the occasional time when this happened, the header would chuck a wobbly and revert back to the Suckerfish Style dropdowns. So, initialization was paired back up with their respective source, and we began researching into ways to [listen" for html elements to exist and be ready for replacement.
It turns out there was more than just HTML elements we needed to listen to however. Knowing that the browser got the JS files in order became important when the load balancer would hand the request off to a possibly different machine for each JS file. And so began the research. The base of the code actually is derived from Cameron Adams' piece on "JavaScript load placement](http://www.themaninblue.com/writing/perspective/2004/09/29/.) One of the issues mentioned in the commnets is that Safari doesn't necessarily know proper height and width, even when the object nodes exist. This caused sIFR some problems when it couldn't generate a flash object of the proper size. Michael Palacios suggested using attributes such as 100% since we can see and predict scalability in an SWF when it's the only thing in a browser window. Unlike traditional sIFR, the generated node is uncaring of its height and width, instead adopting a [100%" of the containing div element for width and height. This non-semantic div can then be styled, letting the flash inside of it scale appropriately. If you'd like, you can browse the prototype (very primitive) below. I mention it primarily because it is a way to solve the repaint problem in browsers. Because the height and width are always at 100%, the dependancy for scaling is moved out of the node creation and into the ActionScript itself.
All that remained then (post repainting problems) was to perform the replacement as quickly as possible, as soon as all the elements were available. Since there was no guarantee of the JavaScript being fully loaded as per the multiple server problem mentioned at the start of this piece, the call could not be placed inline in the HTML. The end result of all of this was adapting Cameron's Scheduler JavaScript in order to support various types of load checks in order to ensure all components were loaded correctly.
The most notable difference is the inclusion of some additional parameters. In addition to looking for an HTML attribute, we also check for the existence of JS files and variables. At the end of each JS file, the following two lines will add itself to the [loaded" list. A generic object is given keys for every JavaScript file that is loaded. We can then use the above code to check this object for any files which have been loaded.
Lastly, we need a line to invoke the scheduler with the function to run:
And there you have it. You can call the scheduler with the above line. The script runs the instant all criteria have been met, even with the sources coming from different machines at different speeds.
Drawbacks of Scheduling
It's worth noting that if the replacement or javascript functionality depends on the screen to be "painted" before functioning, this will cause some large problems most notably in Safari. Additionally, there's a bit of concern about processor load with the 1 ms wait time. After running it live on Gaia for a day and communicating with users, they don't seem to have encountered any issues with the setTimeout usurping all of their clock cycles. However, if your goal is DOM interaction and property setting, this is ideal for avoiding a wait time on additional elements to complete rendering.
In response to "Scheduling JavaScript: Another Way to onLoad":
Because of the loading problem, have you thought of doing a combined JS file?
I understand that two different files are probably needed for updates, or different pages needing different files.
However, this could be done using a PHP file.
I know because I needed a peice of JS that’d have the user’s name & SID as variables, in my forums.
So I simply had a PHP file with a header decleration telling the browser that it was looking at a Javascript file, & the user’s session ID and stuff at the top being printed to the file, then just the rest of the file as normal.
Whist this isn’t that useful, it could work this way.
The file you’d put in the page would be “javascript.php?1=header&2=common” and so on, then the page would simply include the files requested in the GET data.
‘Course, you’d put in a few file name checks, to be safe, and have it so that only javascript files can be included by not including their extention in the GET data.
If there’s only one file, which is sent at a constant rate, then the code will be included in the right order. :3
Hope this was hopeful.
~Alex (Mwa on Gaia.)