Expanding the limits of scripting
Why does it matter? Well, simply put, correct handling of application objects in a Web app is the difference between an efficient Web page and a slow, awkward one. To say it kindly, the IT pro with a maverick attitude thinks of Web app objects at the window-object level first and foremost, and the truth is that most coders of this stripe don't mind handling lower-level page features outside the script. They simply accept that an unscriptable object must be handled via tags, and plug those features in the hard way.
But this makes for inefficient scripting, because DOM objects are scriptable by definition, and a hierarchical object in browser memory is automatically tied to its subsidiary components, making them far easier to manipulate (and availing you of all the power of your scripting language). If you're not taking advantage of these built-in relationships, you're working too hard.
If you really want to be an effective Web designer, your best bet (under the circumstances described above) is to understand what DOM is supposed to give you, and work your way backwards. The idea is top-down planning, visualizing what your application components are doing in your desired end result, and creating an object hierarchy and appropriate handling as you work your way back to code.
The DOM hierarchy
DOM is a set of built-in relationships between application objects that your scripting language is able to manipulate. This hierarchy bestows the power of Object Oriented Programming (OOP) on these features of your application, providing for their efficient handling in your script code, tighter browser memory efficiency, and the reduction in overhead that you expect in an object hierarchy. Such objects are mapped by the browser at page load, becoming part of the app's functional object model.
This mapping happens according to the DOM hierarchy. In the beginning you have the highest level, the Window Object. By definition, it contains everything else. The next level down is the Document Object, the conceptual workhorse of the DOM paradigm. Lateral to the Document Object are the Location Object, Frame Object, and History Object.
The Document Object forms the container for its subsidiary objects: the Applet Object, the Image Object, the Form Object, the Link Object, the Plugin Object, the Area Object, the Anchor Object, and the Layer Object. From the names alone, you can begin to sense how this hierarchy fits together.
An additional layer of 11 lower-level objects is contained within the Form Object, and there are several miscellaneous DOM objects that exist outside the hierarchy.
Supercharging your scripts
Be aware that a browser will passively grab and make scriptable those objects that meet the DOM criteria, so you have all the resources of OOP at your disposal without really lifting a finger. Specifically, DOM objects have properties and methods, and are availed of OOP event handling.
The properties (data elements) of a DOM object are its functional links to your scripting language. You can get them all from DOM and set some of them via your script. Examples of this include color variables, title, and URL for a Document Object, and form, type and name variables for a Text Object.
To know the specifics of DOM data elements available to you, you need to refer to the documentation of your scripting language.
DOM power cranks up a notch with its built-in methods. Scripting languages derive most of their power from these methods; when you've used these methods in the past, you may not have been aware that they are DOM-driven, but this is why scripting languages beat the socks off roll-your-own HTML. "Method" in this context implies exactly the sort of embedded function that you see in other object-oriented programming. Examples include open(), close(), and write() for a Document Object, or focus() and select() for a Text Object. As you have come to expect, arguments may be included with methods. The specifics of your scripting language's implementation of DOM methods are given in your scripting language documentation.
Event handling is made extremely convenient by the alliance between your scripting language and DOM event handlers. The idea, in a typical Web app, is to permit the user (via the browser) to initiate events via page objects and to set in motion the manipulation of data at a lower level. DOM event handlers do most of this work. In DOM you don't have to specify any of these events in your script. It's already there—you just need to let the event handler sense the event. It will then tell the script what to do next. Here again, you may have worked with these event handlers in the past without realizing you were plugged into the DOM hierarchy. It's important to note that, apart from differences in scripting languages, the major browsers have varying levels of compatibility when it comes to these event handlers.
DOM objects as building blocks
Once you have a handle on the DOM hierarchy, its relationships to scripting and browsers, and its OOP features, you can go beyond simply writing more efficient scripts: You can use the objects of the DOM hierarchy as building blocks for far more sophisticated Web apps than you've ever imagined writing. You can create complex structured documents and employ sophisticated navigation techniques that can empower a Web app to the level of the most intricate in-house real-time database apps. You can even assemble virtual documents for your client's Web users' convenience from multiple sources and keep everything straight via DOM.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.