AJAX In Action [281]
planets.Planet=function
(id,system,name,distance,diameter,image){
this.id=id;
...
logger.append("created planet object '"+this.name+"'");
}
Similarly, we can add logging statements to the ObjectViewer code when we edit values and launch pop-up subwindows, to the ContentLoader object when we load network resources, and so on, in order to track the behavior of our codebase while it is running. We can style important messages, for example, network failures:
net.ContentLoader.prototype.defaultError=function(){
logger.append("network error! "+this.url, "urgent");
}
Figure A.10 illustrates the logger console in operation as part of the modified planet viewer application.
This demonstration shows how straightforward it is to add simple logging capabilities to an Ajax application. The system is considerably simpler than server-side logging frameworks such as Apache’s log4j. We leave it as an exercise for the reader to add multiple categories of logging that can be turned on and off independently.
Now let’s move on to our next type of tool: the DOM inspector.
Licensed to jonathan zheng 582 APPENDIX A The Ajax craftsperson’s toolkit Figure A.10 The logging console in operation, monitoring object creation, network activity, user edits, and so on. We have added a second network request to a nonexistent server resource, moons.xml, to demonstrate the display of the styled logging message. A.4 DOM inspectors In an Ajax application, it is common to modify the user interface by modifying the DOM programmatically. Using a JavaScript debugger, we can walk through our DOM manipulation code one step at a time and ensure that it is doing what we want it to do. The DOM, however, is still one step removed from the view presented to the user. We may be confident that our code is altering the DOM in the way that we think it is, but this won’t necessarily translate into the user interface that we expect. A DOM inspector is a tool that allows the developer to inspect the relationships between the DOM tree that our code works with and the visible interface that the end user sees. DOM inspectors need to be tightly integrated with the browser and always support only one make of browser. The most popular DOM inspector is the one that ships with Mozilla Firefox, so we’ll look at that first, and then we’ll look at the alternatives for Internet Explorer. Licensed to jonathan zheng DOM inspectors 583 A.4.1 Using the Mozilla DOM Inspector The DOM Inspector tool is bundled with Firefox but needs to be selected as a custom option during installation. If the DOM Inspector is installed, it will appear in the browser’s menu system under the Tools menu as the option DOM Inspector. When initially opened, the DOM Inspector consists of two panes side by side (figure A.11). The left-hand pane presents a tree-table widget, typically showing only a document and an HTML node initially. The nodes may be opened to reveal a head and body to the document, and within the body, an assortment of nodes representing the HTML markup of a page, plus any elements that have been constructed programmatically. Where nodes have been assigned ID or CSS class attributes, these will be displayed in additional columns of the tree-table widgets. This tree widget is synchronized to the page being displayed in the main browser window. Selecting a tree node with the mouse will make the related element in the page layout flash a red border. The relationship is two-way, too. By invoking the Search > Select Element by Click menu option on the DOM Inspector, the user can click on the web browser window and highlight the tree element corresponding to the element clicked upon. (There’s also a toolbar button for this functionality.) The right-hand pane lists information about the current node in one of several possible formats, including DOM node, CSS style rules, and as a JavaScript