12.1. The Web Browser Environment
12.1.1. The Window as Global Execution Context
var answer = 42; // Declare and initialize a global variable window.answer = 42; // Create a new property of the Window object
12.1.2. The Client-Side Object Hierarchy and the Document Object Model
An object referenced through the current window or through some other Window object may itself refer to other objects. For example, every Document object has a forms array containing Form objects that represent any HTML forms appearing in the document. To refer to one of these forms, you might write:
To continue with the same example, each Form object has an elements array containing objects that represent the various HTML form elements (input fields, buttons, etc.) that appear within the form. In extreme cases, you can write code that refers to an object at the end of a whole chain of objects, ending up with expressions as complex as this one:
Figure 12-1. The client-side object hierarchy and Level 0 DOM
Note that Figure 12-1 shows just the object properties that refer to other objects. Most of the objects shown in the diagram have quite a few more properties than those shown.
12.1.3. The Event-Driven Programming Model
In the old days, computer programs often ran in batch mode -- they read in a batch of data, did some computation on that data, and then wrote out the results. Later, with time-sharing and text-based terminals, limited kinds of interactivity became possible -- the program could ask the user for input, and the user could type in data. The computer could then process the data and display the results on screen.
If you are not already accustomed to the event-driven programming model, it can take a little getting used to. In the old model, you wrote a single, monolithic block of code that followed some well-defined flow of control and ran to completion from beginning to end. Event-driven programming stands this model on its head. In event-driven programming, you write a number of independent (but mutually interacting) event handlers. You do not invoke these handlers directly, but allow the system to invoke them at the appropriate times. Since they are triggered by the user's input, the handlers will be invoked at unpredictable, asynchronous times. Much of the time, your program is not running at all but merely sitting waiting for the system to invoke one of its event handlers.
Copyright © 2003 O'Reilly & Associates. All rights reserved.