Javascript [Electronic resources] : The Definitive Guide (4th Edition) نسخه متنی

12.1 The Web Browser Environment

To understand client-side
JavaScript, you must understand the conceptual framework of the
programming environment provided by a web browser. The following
sections introduce three important features of that programming
environment:

• The Window object that serves as the global object and global
  execution context for client-side JavaScript code
  




• The client-side object hierarchy and the document object model that
  forms a part of it
  




• The event-driven programming model

12.1.1 The Window as Global Execution Context

The primary task of a web browser is to
display HTML documents in a window. In client-side JavaScript, the

Document object represents
an HTML document, and the Window object represents the window (or
frame) that displays the document. While the Document and Window
objects are both important to client-side JavaScript, the Window
object is more important, for one substantial reason: the Window
object is the global object in client-side programming.

Recall from Chapter 4 that in every implementation
of JavaScript there is always a global object at the head of the
scope chain; the properties of this
global object are global variables. In client-side JavaScript, the
Window object is the global object. The Window object defines a
number of properties and methods that allow us to manipulate the web
browser window. It also defines properties that refer to other
important objects, such as the
document
property for the Document object. Finally, the Window object has two
self-referential properties, window and
self. You can use
either of these global variables to refer directly to the Window
object.

Since the Window object is the global object in client-side
JavaScript, all global variables are defined as properties of the
window. For example, the following two lines of code perform
essentially the same function:

var answer = 42;     // Declare and initialize a global variable
window.answer = 42;  // Create a new property of the Window object

The Window object represents a web
browser window or a frame within a window. To client-side JavaScript,
top-level windows and frames are essentially equivalent. It is common
to write JavaScript applications that use multiple frames, and it is
possible, if less common, to write applications that use multiple
windows. Each window or frame involved in an application has a unique
Window object and defines a unique execution context for client-side
JavaScript code. In other words, a global variable declared by
JavaScript code in one frame is not a global variable within a second
frame. However, the second frame

can access a
global variable of the first frame; we'll see how when we
consider these issues in more detail in Chapter 13.

12.1.2 The Client-Side Object Hierarchy and the Document Object Model

We've seen that the Window object is the key object in
client-side JavaScript. All other client-side objects are connected
to this object. For example, every Window object contains a
document property that refers to the Document
object associated with the window and a location property
that refers to the Location object associated with the
window. A Window object also contains a frames[] array that
refers to the Window objects that represent the frames of the
original window. Thus, document represents the
Document object of the current window, and
frames[1].document refers to the Document object
of the second child frame of the current window.

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:

window.document.forms[0]

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:

parent.frames[0].document.forms[0].elements[3].options[2].text

We've seen that the Window object is the global object at the
head of the scope chain and that all client-side objects in
JavaScript are accessible as properties of other objects. This means
that there is a hierarchy of JavaScript objects, with the Window
object at its root. Figure 12-1 shows this
hierarchy. Study this figure carefully; understanding the hierarchy
and the objects it contains is crucial to successful client-side
JavaScript programming. Most of the remaining chapters of this book
are devoted to fleshing out the details of the objects shown in this
figure.

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.

Many of the objects pictured in Figure 12-1 descend
from the Document object. This subtree of the larger client-side
object hierarchy is known as the document object model
(DOM), which is interesting because it has been the focus of a
standardization effort. Figure 12-1 illustrates the
Document objects that have become de facto standards because they are
consistently implemented by all major browsers. Collectively, they
are known as the Level 0 DOM, because they form
a base level of document functionality that JavaScript programmers
can rely on in all browsers. These basic Document objects are the
subject of Chapter 14 and Chapter 15. A more advanced document object model that
has been standardized by the W3C is the subject of Chapter 17 and Chapter 18.

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.

Nowadays, with graphical displays and pointing devices like mice, the
situation is different. Programs are generally event driven; they
respond to asynchronous user input in the form of mouse-clicks and
keystrokes in a way that depends on the position of the mouse
pointer. A web browser is just such a graphical environment. An HTML
document contains an embedded graphical user interface (GUI),
so client-side JavaScript uses the event-driven programming model.

It is perfectly possible to write a static JavaScript program that
does not accept user input and does exactly the same thing every
time. Sometimes this sort of program is useful. More often, however,
we want to write dynamic programs that interact with the user. To do
this, we must be able to respond to user input.

In client-side JavaScript, the web browser notifies programs of user
input by generating

events .
There are various types of events, such as keystroke events, mouse
motion events, and so on. When an event occurs, the web browser
attempts to invoke an appropriate

event
handler
function to respond to the event. Thus,
to write dynamic, interactive client-side JavaScript programs, we
must define appropriate event handlers and register them with the
system, so that the browser can invoke them at appropriate times.

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.

The next section explains how JavaScript code is embedded within HTML
files. It shows how we can define both static blocks of code that run
synchronously from start to finish and event handlers that are
invoked asynchronously by the system. We'll also discuss events
and event handling in much greater Chapter 19.