Foundation.ClientLoader is a class designed to free the webmaster from the details and maintenance of a class. Whoever created the class obviously needs to know the details, but not necessarily the webmaster (unless they are the same person). The webmaster needs to be able to add simple script tags on their page and be able to forget about them, knowing they will always work and be up-to-date.
This is done by creating a "loader" class. This class is a bridge between the web page and the potentially many and continuously updated objects it uses. The loader class might expose one or two "write to page" or "add to page" methods. When called, it is the job of the loader to request a list of the necessary script files, include them in the page, execute any necessary setup code, and then execute the desired function of the target class.
For example, GamesByEmail.com has a Set game. It is a multiplayer game using AJAX techniques. To make that game available for any webmaster to easily include on their site, GamesByEmail.com created a Set game loader class that extends Foundation.ClientLoader. Any site on the web may include that game on any page with the following simple, static scripts:
And presto, a multi-player game appears like so:
Select sets in the game above. Be quick! You are competing against other Set players.
Note that the loader class is designed to be short, static and cachable. It should hardly ever change. Additions can be made, but backwards compatability should always be maintaned (which should be easy to do).
The actual game class code can update as necessary. When the a method of the loader class is called, it always makes a call (never cached)
to its mother ship to get a list of necessary files. In this case, the list is available here (you see this URL in the resource pack of the class above):
When all the necessary scripts have been loaded, the loader class then makes the one necessary method call to the game class (the last line above).
As you can see, loaders simplify the job of the webmaster by reducing the necessary HTML to only two scripts and eliminating maintenance of that code completely. A webmaster need only add the following two lines of code to add a Set game to a page. Since the code in the two files are static, there is no need to worry about caching or updating links. The actual Set game class used is always up-to-date:
Another feature of loaders is that they are light weight and only load their classes when invoked. So a site can
include a loader and if it is not used, there is little waste. The server does not use any processor time as the HTML to
include the loader is static. Foundation.js is small, the loaders are very small, and both can be indefinitely cached,
so very little bandwidth is used. Also because they are small, the client uses very little processing time. Yet powerful
classes and large files can be loaded on demand. For example, a game loader was added to this page, and it's method is only
called when the following button is pushed. Then, large class files to preview a complicated game are loaded, and the
game is added to the page. But this page was able to initially render quickly because these classes are included and parsed
only if and when needed.
Foundation.js is designed to be the bare minimum to create loaders. That is it's sole function. The other classes in Foundation.js are only there because they are used by loaders. There is almost zero fluff. The idea is to create a simple, unchanging way of including all the utility scripts, class scripts and dependencies through loaders. The benefits: