14.0 Introduction
JavaScript-enabled
browsers have always provided a level of control over page content so
that scripts can influence what the visitor sees on the page. But it
took sophisticated document object models and the automatically
reflowing page features of browsers such as Internet Explorer 4 and
Netscape 6 to give scripters carte blanche over the page content,
both during page loading and after (within security boundaries, of
course). This chapter focuses on how to generate content that goes
into the page and manipulate the existing content of a page. The next
chapter picks up where this one leaves off, showing several specific
applications of these powers.
Web programmers who spend most of their time coding for server
processing frequently overlook the power that a scripted client can
provide to an otherwise dead and dull web page. Their (quite logical)
train of thought is to have the server work its magic to assemble
content that shoots its way to the browser, where users read it and
perhaps enter various things into forms. The browser then sends the
form back to the server, where more programming processes the user
input. It's powerful stuff on the server, and
applications involving transactions and database access need that
power running right where it is.
Users, however, are accustomed to direct
manipulation of data and instant feedback from their experience with
standalone applications running on their computers. When you change
the font characteristics of a selection in a word-processing
document, the change is instantaneous; when you sort the columns of a
spreadsheet, the sorting occurs in a blink of the eye. Waiting for a
submission to the server, remote processing, and delivery of the
reconstituted page is not fun, even when you have a broadband
connection to the Internet.
Unless the content that needs manipulation is updated so frequently
in the server database that it requires constant updating on the
client, it is likely that a set of retrieved data can be delivered
with the document such that interactivity with the
data�transformations of the rendering in particular�can
be handled entirely on the client. Not only is the response
instantaneous, but you also free the server from some of its burdens.
This chapter and the next are all about pages that may look entirely
different from the way they were delivered by the server because the
user is able to sort tables, experiment with the body text content,
and even filter content based on user preferences. Power to the
people, in a sense.
Only time will tell if server-centric developers will feel
comfortable enough with client-side dynamism to take full advantage
of it. Early horror stories about incompatibilities among browser
generations and brands are increasingly less relevant as the
installed base of W3C DOM-capable browsers reaches critical mass.
|