In the roll-your-own world of HTML, it’s easy to get swept up in the heady process of Web page creation and forget that we’re programming. Paradoxically, Web pages often become things of beauty in our eyes, as lovingly rendered as a painting. In those situations, we can lose sight of functionality, and more importantly, the fact that the Web page is ultimately a practical tool for the end user.
DHTML takes away your paint brushes and gives them to your user. Your Web pages can and should respond to users with intelligence, sensing intent, data needs, and possibly even personal preferences (if appropriate), modifying the interaction accordingly. (You can be assured that if you don’t offer this dynamic functionality, your company’s competitors will.)
The Document Object Model is the neglected child in the DHTML family, but there is little overstating its potential in Web applications. It bestows the full power of object-oriented design upon the interpreter-level anarchy of HTML. Your scripting language avails you of the class, method, and inheritance features that DOM passively imparts; but knowing the specifics of the model will take you into a whole new realm.
Design shared-processing applications
One powerful feature of DOM is the ability to hand off processing tasks to the client, giving you a net result of greater application efficiency and speed. You can generate data presentation code in real time on the client; you can hand off large data sorting tasks to the client; and you can create, in real time, client-specific background processing code to execute on the client machine, to perform operations on client-requested data.
How is this done? One enabling factor is the data island, an XML feature supported by IE and Netscape Navigator that allows you to pull in XML code fragments from external XML files, or even plant the fragments in the page. Since you’re passing code to the client for execution by the client browser, the name data island may seem a little misleading, but it’s essentially conditional code that can be used to personalize the user’s processing and offload it to the client system.
And what does this XML code do? It generates HTML in real time to meet a specific user’s needs, either in generating a customized interface for increased efficiency, or for handling requested processing services.
The old-fashioned approach
A traditional HTML application acts as a bridge between user and database. It conforms to a traditional IT geography that places data on the server and to the user on a remote system with independent processing resources. The application enables a query interface (executing on the client system) that validates the user, implements appropriate security/access, accepts a query on the server side, performs retrieval tasks on the server side, formats the data on the server side, and then delivers the data to the client system for presentation.
The appropriate HTML document for presentation of whatever the user has requested is stored on the server side and delivered to the client machine for execution as written. When pitching rather than catching, data being submitted to the server from the client is generally swallowed whole by the client browser and formatted on the server side.
What’s wrong with that picture? Nothing, as far as it goes; but when a dynamic approach is considered, the following weaknesses emerge in the old method:
- It relies very heavily upon prewritten HTML presentation routines that must be separately maintained and accessible on the server side.
- The HTML application itself is unnecessarily complex and bulky because of its excessive conditional processing, making it difficult to maintain and increasing the risk of browser errors.
- Even with a vast library of HTML presentation conditionals, there are limits on the degree to which a user-specific, data-driven interface can be realized.
- It is less practical to pass processing tasks to the client system, because the degree to which the tasks may be whittled down to a reasonably efficient minimum is constrained by the incidental match-up between an individual user’s needs-of-the-moment and the available static conditional processing routines.
- The heavy processing burdens are all on the server side.
- There are lots and lots of server hits in this scenario, because every new condition and every new task can require a visit to the server for new HTML code.
The dynamic approach
Here’s the better way. A user session sends the application from the server to the client browser. The user’s query choices activate inline XML code, causing HTML presentation and/or processing code to be generated on the client and run on the spot; or, at worst, XML code stored in an external file on the server is pulled across to the client, permitting a wide range of possible HTML code generations to be executed for the user in a single trip. This makes possible an efficient off-loading of processing tasks (heavy sorting, table creation, and so on) to the client without a burdensome increase in communications overhead.
With XML data islands and DOM’s power to handle them, then, a significant amount of client-to-server chatter is eliminated. Since HTML code is generated in real time and is specific to the user’s needs, the presentation or processing subtasks will be dead-on, rather than loose fits; and because the client system is keeping all the balls in the air, it becomes possible to keep a cascading series of increasingly refined tasks sustained across a single session without lengthy communications delays or processing hold-ups. Such a dynamic interaction and customized processing environment makes it possible to execute very detailed applications (even related applications in series) with peak efficiency and minimal risk of communications or processing bottlenecks.
Letting DOM features drive your design
This scenario is intended to stimulate your thinking in the Web app design process. It should be clear that you can radically simplify HTML designs and offer users far greater efficiency and flexibility by using the XML-to-HTML method of real-time client browser code generation.
What does all this have to do with DOM? Well, though the browsers offer the XML data island feature that carries the code generator, it is DOM that makes that code executable. XML data islands are ID-tagged, and can be bound to an HTML tag to enable conditional activation of the code (external code can be referenced with the SRC attribute).
The dataSrc and dataFld attributes are used to bind data islands to HTML tags in the application (do it the long way and you’ll see how efficient this is) and to populate individual HTML fields. DOM methods allow you to load and execute XML code fragments from external sources in a single URL call; DOM’s createDocument() in the DOMImplementation interface handles all the transfer tasks for your server-to-client processing hand-off without the overhead you’d encounter otherwise.
Looking for new or a more feature-rich XML or HML editor, download trial software from Builder Tools.
From design to development
The downside is that IE and Netscape do not handle all of these tricks the same way, and the W3C has not yet put forth a standard for DOM and data-driven XML data-island handling. However, these techniques are still worth learning, and now that the design flag has been waved, I’ll look at several specific presentation and processing examples in upcoming articles.