Applying the Image Cache API
Theory is all very well, but the proof is in the pudding. So let's move on to some concrete applications.
If all you're after is a facility to preload a page's static image content and then display it (like the Dreamweaver code we started with), you can add a little code to do this programmatically (see Listing 2). autoload.js exposes two methods. The first, loadImages(), creates and loads an ImageGroup after populating it with the name attribute of each IMG tag in the document. Then setImages() reconnects the newly loaded images with the document.
If you want the images to preload as soon as you open the page, all you need to do is include the relevant script files and hook the document's onload event; everything else happens automatically. This means your resulting HTML can be as simple as this:
<!-- These images will all get preloaded; just substitute
"name" for "src"
If you unzip the demo project that accompanies this article and run preload.htm
, you can see auto-load.js
in action. Usually, you would hook up loadImages()
as above, but in preload.htm
I've added a button to do this explicitly.
You might also want to take a look at slideshow.htm (see download, left column), which implements the hypothetical slideshow we discussed earlier, providing feedback with a progress bar and rescaling images on the fly so that they fit within the bounds of the viewing box. After loadSlides() kicks off a group of images to load (pictures of Warkworth's A&P Festival, to be precise), execution first loops around updateProgress(), increasing the length of the progress line as the various images complete their loading, and subsequently around updateSlide(), which cycles through the group's image set at two-second intervals.
Ultimately the ability to control how and when images load can be a powerful asset. For example, if you embedded the ImageCache in a hidden, top-level frame, it could take responsibility for all the images on a Web site. You could even set a timer so that, while you were viewing one page, it would be secretly preloading the images for the next. Because image data contributes more to the bulk of most HTML pages than any other factor, this could have a significantly beneficial effect on the perceived loading and rendering time of the site as a whole.
The techniques I've presented could easily be extended to provide caching support for other asynchronous operations within the DOM, such as preloading XML documents or collections of HTML pages associated with other frames. Half the battle is learning to respect the DOM's event-driven model. Once you do you'll realize how little additional code you need to get event handlers and code coexisting in a meaningful workflow rather than working in conflict.