Review
Product Description
On numerous online forums for JavaScript and DHTML, the majority of questions begin with "How do I...?" This new Cookbook provides the answers. After reading thousands of forum threads over the years, author and scripting pioneer Danny Goodman has compiled a list of problems that frequently vex scripters of various experience levels. He has now applied state-of-the-art ECMA and W3C DOM standards and used best practices to create this extensive collection of practical recipes that can bring your web pages to life.
The JavaScript & DHTML Cookbook is all about adding value to the content of a web page. The book focuses on practical and sensible applications of scripting, rather than flying images and gratuitous color changes. For every problem Goodman addresses, there's a solution or "recipe"--a focused piece of code that web developers can insert directly into their applications. Yet, rather than just cut-and-paste code, you also get explanations of how and why the code works, so you can learn to adapt the problem-solving techniques to your designs.
The recipes range from simple tasks, such as manipulating strings and validating dates in JavaScript, to entire libraries that demonstrate complex tasks, such as cross-browser positioning of HTML elements and sorting tables. This book contains over 150 recipes on the following topics:
- Working with interactive forms and style sheets
- Presenting user-friendly page navigation
- Creating dynamic content
- Producing visual effects for stationary content
- Positioning HTML elements
- Managing browser windows and multiple frames
About the Author
has been writing about personal computers and consumer electronics since the late 1970s. In 2001, he celebrated 20 years as a free lance writer and programmer, having published hundreds of magazine articles, several commercial software products, and three dozen computer books. Through the years, his most popular book titles on HyperCard, AppleScript, JavaScript, and Dynamic HTML have covered programming environments that are both accessible to non-professionals yet powerful enough to engage experts. His JavaScript Bible book is now in its fourth edition. To keep up to date on the needs of web developers for his recent books, Danny is also a programming consultant to some of the industry's top intranet development groups and corporations. His expertise in implementing sensible cross-browser client-side scripting solutions is in high demand and allows him to, in his words, "get code under my fingernails while solving real-world problems." Danny was born in Chicago, Illinois during the Truman Administration. He earned a B.A. and M.A. in Classical Antiquity from the University of Wisconsin, Madison. He moved to California in 1983 and lives in a small San Francisco area coastal community, where he alternates views between computer screens and the Pacific Ocean.
Excerpted from JavaScript and DHTML Cookbook by Danny Goodman. Copyright © 2003. Reprinted by permission. All rights reserved.
10.0 Introduction
No web page is (or should be) an island. Just as there is a way to reach the page, so should there be one or more ways to navigate to other destinations, either within the same site or outside. The HTML hyperlink element—embedded in pages as the rather nondescript tag—is the conventional, nonscripted way to provide a clickable avenue for the user to navigate to another page. But more sophisticated user interface designs frequently require Dynamic HTML to assist with the presentation of navigation options and the very act of navigating.
The location Object
Each window (and frame) object in every scriptable browser has a location object whose properties contain information about the URL of the page currently loaded into the browser. This is an abstract object, meaning that the object has no particular physical presence visible on the page—except perhaps the URL that appears in the browser’s Location or Address field. But the location object does not control what the user sees in the Location/Address field unless the browser succeeds in navigating to a page you assign to the location object.
Properties of the location object are read/write. The individual properties reveal components of the URL (and even the entire URL) of the loaded page. Without any restrictions to this information, however, scripts could spy on your browser activity without you knowing it. For example, imagine entering an unscrupulous web site that looks like the Google search page. In fact, you could be viewing the actual Google search page within a frameset whose second frame is hidden from view. A script in the framesetting document or the other frame could inspect the location object of the visible frame every ten seconds, accumulating a record of every page visited in that frame. The information could then be sent back to the spoofer’s server without the user’s knowledge or permission. Despite the fact that, in some situations, knowing the URL of another frame or window could enhance the user experience, the potential for invasion of privacy has forced browser makers to clamp down on the reading power of location object properties.
Browsers observe various types of security policies to help protect a user’s privacy. The policy that applies to the location object is known as the same origin policy. If a script running in a page served by one server and domain wishes to inspect the location object of another frame or window, the document in the other frame or window must also be served by the same server and domain. If the user navigates in one of the frames to another domain or server, the same origin policy fails (even though the frameset is still served within policy), and the location information is not accessible to the other frame.
Partially as a result of a variety of security holes in Internet Explorer for Windows, Microsoft occasionally clamps down so tightly on a potential threat that attempts to read location object properties of another window or frame—even from the same origin—result in a security-related script error (such as "Access denied."). From a reliability standpoint, reading the location object is best done in the same page as the script doing the reading. As you’ll see in a few recipes in this chapter, there are some good reasons to do this.
All this security stuff, however, applies only to reading the location object’s property values. You can assign new values to the properties across window and frame boundaries with impunity.
Passing Data Between Pages
A very common model in the web-application world is essentially a forms-based navigation system, in which virtually every page is a form whose values are submitted as a way to progress to the next page. When the submitted form reaches the server, programming on the server dissects the form controls’ name/value pairs. Some of the pairs may get shunted off to a backend database. Other bits may be reformulated as values of hidden input elements in the page that gets assembled for return as the next page. Once the second page is served up, the server doesn’t know whether the user is still connected to the site or has perhaps navigated off somewhere else. In other words, the server simply reacts to requests from a browser, returning a page in response.
The server may be programmed to keep some temporary information about the user on hand, identified by a session ID. That session ID is passed down to the browser with each returned page so that when the next request arrives, the server program can tie together requests that come from a single browser. Some server programs that assemble pages on the fly for each visitor (such as amazon.com) populate the href attributes of all intrasite links with the session ID so that the server can keep passing the ID along from page to page. It may sound a bit crude, but it is much more bandwidth-efficient than maintaining a full-time connection between server and browser (or between thousands of browsers at any instant for a popular public site).However, not everyone has the requisite programming skills or server access to accomplish this server-based way of passing along live information from one page to another. By the same token, security restrictions in browsers prevent the random reading and writing of data to the local hard drive of users. Fortunately, with the help of JavaScript and various pieces of the object models, you do have a few different ways to get information from one page to another without having to involve the server. Recipes 10.4 through 10.6 show these approaches using cookies, frames, and URLs. For example, consider the case in which a user has bookmarked just one content page from a frameset whose other frames provide vital site navigation tools.
