Two solutions for adding forward/backward capabilities to AJAX applications using Dojo

Introduction: The most obvious feature of Ajax-based WEB applications is the use of the native-supported XMLHttpRequest object in the browser with the backend server for data communication, because this type of communication does not require page refresh action, so no matter how many times with the background communication, browser URL will remain unchanged at the initial address. One problem with this is that changing page state information cannot be recorded in the browser's history stack, making it impossible for users to switch between different status pages through the browser's forward/rewind buttons. As one of the most popular JavaScript development kits of today, Dojo offers two dojo.back and Dojo.hash methods for solving such problems in its latest release version 1.4. The purpose of this paper is to analyze and compare the technical principles behind the two methods, give a sample solution based on two methods, and explore how to choose a suitable solution for different types of Ajax applications.

The basic thinking and technical basis of problem solving

Browsers are able to support a forward/backward operation between pages visited by the user, relying on internally maintained history objects. For security reasons, browsers do not allow JavaScript scripts to add or write to the object, but only through history. Back/forward () and other methods to access. Since the page state changes, it is not possible to directly affect the browser's historical information through the script, then only by changing the URL to trigger the browser to add a new historical record. This means that the Ajax application of different page states and URLs for a one-to-one mapping, and can be rolled back or forward to a URL, the application itself can be in the page without refreshing to jump to the correct page state.

So how do you change the initial URL of an Ajax application, while this change doesn't cause the page to reload? There is only one answer: a "fragment identifier" (fragment identifier) that is used for locating a resource fragment within a page, a string (hash string) after the "#" symbol in the URL. When a browser requests a resource from the server side, the fragment identifier is not sent along with the base URL to the server side, but only after the result returned by the server helps the browser quickly navigate to the resource fragment identified by the corresponding anchor (anchor), even if a corresponding anchor point cannot be found. Browsers also do not make an error. It is based on this feature of the browser that the mapping relationship between the building fragment identifier and the page state becomes the basis for solving such problems.

Currently, browsers other than IE are able to add new URLs resulting from a hash string change to the browser's history stack as a new record, and the JavaScript script can get and set the hash string by reading and writing to the Window.location.hash property , which indirectly achieves the purpose of affecting browser history through scripting. In particular, IE does not consider it necessary to equate the change caused by an illegal fragment identifier with a change in the URL and no action to record historical information, and the most common solution is to embed a hidden iframe in the page because the browser can The src attribute of the IFRAME node is tracked by historical record, so that the link between the fragment identifier and the page state can be established in IE by establishing a corresponding chain of "page URL-page IFrame URL-page state".

Comparison of the principle of dojo.back and Dojo.hash implementation

Now that we've identified the solution to the problem, then go to the specific implementation of the point of view, the establishment of this page URL and the mapping between the state of the page, there are two ways to implement: one is the page state of the migration-oriented, after the state first change, for the page URL to add the corresponding hash string, this way for Dojo.back, the second is based on the change of the URL, the change of the page before the state changes the hash string, and then the page based on the information contained in the page to complete the status of the migration task, this way is Dojo.hash recommended. In the next part, this article will carry on a more thorough analysis introduction to the realization mechanism behind these two kinds of methods.

Dojo.back Realization Principle

Since its 1.0 release, Dojo has been providing developers with Dojo.back-based solutions for browser history issues. Dojo.back supports two forms of forward/backward operations, the difference between the same body now when the page state changes, the URL is also changed with it. More specifically, developers can choose to add the ability to advance backwards for Ajax applications without changing the browser URL.

The reason for this design is because dojo.back that there is no need for Ajax applications to add "Bookmark collection" This similar ability, there is no need to reflect the changes in the page to the URL above, the user always face a fixed URL on the same. But this kind of flexible design way, also completely is dojo.back the internal specific realization mechanism to decide.