JavaScript and DHTML Cookbook [School & Library Binding]

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. --This text refers to the Paperback edition.