ajax| Standard | program | The browser uses the fragment identifier, and we can create a "ajax-uri" that separates the client part from the server-side part using "#".
JavaScript provides the window.location () function to update the browser's history and address via a URI. In addition, we can use Window.location.hash () to access the fragment identifier directly.
In the following code snippet, you can see how to extend our code by using the OnChange event handler for the selection box, which uses a "Ajax-uri" to update the browser history and address bar.
Backbase and AJAX information for developers. DevNet also has a developer forum.
Backbase Web includes DevNet and a forum to discuss how to use Backbase. In order to show the "rich" and "reach" features of this forum, I will walk through the typical usage of this forum step by step:
1. A developer browses forum reading threads on different topics
2. The developer copies the URI of the thread and pastes it into an email. Friends copy URI from email to browser and open the same forum line
3. The developer clicks the back button to browse the previous thread
Status of the forum interface after several users interact
When the user browses the "BXML" forum and chooses to send "Issue with vertical and horizontal menus", we take a look at the status of the forum interface and the corresponding URI in the address bar.
The forum and current selection are selected and get focus. The requested thread is displayed for reading. The URI contains all the information about the corresponding fragment identifier. Behind the hash, we see the complete state used to record bookmarks and deep linking. "Forum" means that the developer is browsing the forum part of the web address, "forum = 2" means that the BXML forum has been selected, "thread = 211" records the currently selected thread, and finally, the information in brackets: " [5] "means processing multiple forward and bookmark steps.
If you visit the Backbase forum, you will see how the URI is updated when each state changes, even the URI processed by the client and the updated URI of some pages through the XMLHttpRequest object.
Forum interface status maintained by other browser windows
Now let's take a look at what will happen when the developer sends the current URI to a friend. A friend opens a URI in a browser window and wants to see the same interface state. In a new browser, this state needs to be recreated. In our case study, I simulated this requirement by copying the URI from the Firefox window to the just opened IE window.
Entering the URI in the browser's address bar immediately generates a server request. Using the previous part of the hash, Backbase.com is loaded, and in the process, the Backbase AJAX engine is initialized. This active Backbase engine talks about reading the rest of the URI hash. From that information, the Backbase engine generates the corresponding state, such as entering the "forum" section, and setting the forum's BXML (id = 2) and thread 211. By loading additional content from the server and updating some interfaces on the client, we have completed the above functions, and there is no page update.
For subsequent processing of browser functions, a new URI will be pushed into the browser's history. This new RUI can be seen in the address bar and can be used for deep linking. "[0]" means that if you use the back button, no state before this state can be returned.
The state of the forum interface when the user clicks the back button
The first step in studying this case is to generate a change in the state of the interface with a new URI through user interaction. In this way, you will see: a new URI is requested and the corresponding state is maintained.
By clicking the back button, users will browse the pages they have read before. The browser handles this request by retrieving the previous URI from the history stack. The Backbase AJAX engine detects this change, reads the previous URI from the history and maintains the corresponding state: enter the "forum" section, select the forum "BXML" (id = 2), and the thread is 192. A URI with the same syntax as the URI above will be seen in the address bar.
This will end the study of this case.
AJAX applications do need a back button
In the past few years, our developers have chosen to develop such a web application interface: the market requires "reach" and is willing to accept less or no "rich". However, the current excitement on AJAX clearly proves that this willingness is actually only temporary. The market now focuses on requiring web applications to be as expressive, interactive, and responsive as desktop applications.
At the same time, end users have become accustomed to the traditional web interaction style. Using the same model and all web interface interactions can increase productivity. End users want to use the back and forward buttons to generate a bookmark, a deep link, and a refresh button, use "find" to search the entire page, and search engines can index AJAX applications.
The AJAX community has accepted the view that it is technically possible to provide support for back and forward buttons and other traditional browser features in AJAX applications, as discussed in this article. Although using the same resources as traditional web development, these features are not easy to implement. But the success of this community will require adding traditional web features to AJAX applications. Therefore, I strongly recommend that AJAX developers support these features when developing AJAX applications.
in conclusion
In this article, I mainly explain why AJAX applications need to follow the traditional web interaction style and provide support for traditional web usability features. I created an application: In this application, I wrote these features into an AJAX application by creating an AJAX URI that contains client state information in the fragment identifier.
From the above code, you can see that a complete and general solution is difficult to get. It is not easy to give general status handling code. The reason is cross-browser incompatibility. The Backbase AJAX engine provides a solution to this problem by providing external demand functions.
references
An Introduction to Ajax by David Teare (dev2dev, August 2005)
Backbase RSS Reader
Top 10 Ajax Applications by Dan Grossman (A Venture Forth, September 2005)
Flash: 99% Bad, by Jakob Nielsen (Jakob Nielsen's Alertbox, October 2000)
A Backbase Ajax Front-end for J2EE Applications by Mark Schiefelbein (dev2dev, August 2005)
Fixing the Back Button and Enabling Bookmarking for AJAX Apps by Mike Stenhouse (Content with Style, June 2005)
AJAX: How to Handle Bookmarks and Back Buttons by Brad Neuberg (OnJava, October 2005).
Uniform Resource Identifier (URI): Generic Syntax (IETF RFC 3986, January 2005)
Ajax forum on the Backbase DevNet
About the author
Mark Schiefelbein has been Head of Product Management at Backbase since January 2005. He organized a global product exhibition of Backbase's rich web application technology.
Original link
http://dev2dev.bea.com/pub/a/2006/01/ajax-back-button.html <html> <head> <script language = "JavaScript" type = "text / JavaScript"> function makeHistory (newHash ) {window.location.hash = newHash;} function reportOptionValue () {var myForm = document.make_history; var mySelect = myForm.change_year; return mySelect.options [mySelect.selectedIndex] .value;} function setOptionValue (value) {var myForm = document.make_history; var mySelect = myForm.change_year; mySelect.options [value-1] .selected = true;} </ script> </ head> <body> <form name = make_history> <select name = change_year onchange = "return makeHistory (reportOptionValue ())"> <option value = "year_1"> Year 1 </ option> <option value = "year_2"> Year 2 </ option> </ select> </ form> </ body > </ html>
As we can see in Figure 2, every change in the selection box will cause the browser address to be updated. Please note that there are some issues in Internet Explorer (IE) that need to use hidden frames for correct behavior, please refer to the articles by Mike Stenhouse and Brad Neuberg for details.
Develop an AJAX application that retains standard browser functionality (3)-WeChat browser ajax fails
Figure 2. History stack is updated when state changes
We now have an event handler that creates a new URI when the value of the select box changes. The new URI uses the fragment identifier to store the information needed to recreate the previous state. Now we can move on to the next feature.
Restore history
Detecting URI changes
Recreate state by URI
In the first step, we updated the client's URI through the window.location.hash () function. This call does not cause a round trip to the server, nor does it cause a page refresh. Therefore, we need to use the Ajax method (on the client side) to handle URI changes.
First you need to add a polling function to periodically check the URI in the browser history. I will use the pollHash () function in the onload event of the page, and it will re-execute every 1000 milliseconds.
This polling function will call the handleHistory () function, which checks if the URI has changed since the last check. We will do this with the help of a global variable named expectedHash.
The last part is to determine if the URI has changed. This change is caused by the event handler in the selection box or because the end user clicked the back button. We do this by setting expectedHash in the event handler of the select box.
<html> <head> <script language = "JavaScript" type = "text / JavaScript"> var expectedHash = ""; function makeHistory (newHash) {window.location.hash = newHash; expectedHash = window.location.hash; return true;} function reportOptionValue () {var myForm = document.make_history; var mySelect = myForm.change_year; return mySelect.options [mySelect.selectedIndex] .value;} function setOptionValue (value) {var myForm = document.make_history; var mySelect = myForm.change_year; mySelect.options [value-1] .selected = true; return true;} function handleHistory () {if (window.location.hash! = expectedHash) {