Part 5: Wrap Up
Coding Techniques
I take a good potion of my coding style and my thinking about objects from a background in Java. As such I prefer to organize my objects as I've done above and attach properties and methods to my own objects. Sometimes this is overkill. JavaScript provides an alternate method of modifying objects via an object prototype. For example, someone else may have chosen to enhance the built in Image object rather then create an entirely new object as I have done. You will see this practice quite often among Flash Developers. For instructional purposes I also prefer the clarity that making an entirely new object provides.
Browser Support for Object Oriented JavaScript
You may have noticed that the example used in this tutorial doesn't work in non-W3C DOM aware browsers (Netscape 4 for example). This was not done because other browsers have a problem with object oriented techniques, but rather as a way to keep the example focused on Object Oriented JavaScript and not the nuances of coding for multiple browsers. I have successfully used custom objects in all version 4 or higher browsers. In fact, creating custom objects that model a browser element (a layer or the window perhaps) is an excellent way to keep the browser specific stuff outside of the flow of your normal logic.
If I were to alter the objects in the example used here to support the three common DOMs (MSIE4, Netscape Layers & W3C) the constructor for our objects might look something like the following bit of code.
// object constructor
function crossBrowserObject(someID) {
// define local properties
if (document.all) {
this.something = document.all[someID];
} else if (document.layers) {
this.something = document.layers[someID];
} else {
this.something = document.getElementById(someID);
}
}
Other forks in browser functionality would be handled in a similar fashion throughout the object.
A Semi-Final Word On Object Modeling
Someone else could have modeled this gallery very differently. The choices made are quite subjective. An example of a different way to go would have been to create a dumber photo object that knew nothing about the page at all but was instead a simple data object that stored the photo's source. In this cause the navigation object, or some other page object would have to act more like an air traffic controller and direct which photo goes where and when.
Additionally, in the modeling the objects used for this interface I really did not put much consideration towards their use beyond this application. For example, we did not create a way to force a photo to load independent of it being used. This might be a very worthy thing of doing, but it was not something that was needed for this application of our image object. When you are building custom objects take a step back and see what needs to be to make them generic enough that you will have a chance at reusing them. Get an idea of the other data it might store or methods it might use. If you don't have to use all the methods right away you don't have to code them (e.g. csnPhotoObject.loadImg()), but make sure they won't clash with anything later. Don't worry if this seems like a lot to think about, I'll cover it in my next article on this topic.
