Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Develop a Reusable Image Cache in JavaScript : Page 3

The asynchronous download ability built into today's browser DOMs is a great way of getting image-heavy pages to build faster, but it doesn't mesh well with JavaScript's single-threading execution model. Use our image cache API to build scripts that work hand-in-hand with asynchronous objects and their events.

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:

<html> <head> <script src="_scripts/load-image.js"></script> <script src="_scripts/auto-load.js"></script> </head> <body onload="loadImages()"> <!-- These images will all get preloaded; just substitute "name" for "src" --> <img name="_images/A1.jpg"> <img name="_images/A2.jpg"> ... etc. </body> </html>

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.

Alex Hildyard is a freelance software consultant and writer, specializing in web technology.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date