Developing AJAX applications that preserve standard browser capabilities

Summary
AJAX applications are praised for their rich expressiveness, more interaction, and faster response; these advantages are obtained by using the XMLHttpRequest object to dynamically load data instead of reloading a new page. In a lot of publicity and excitement, there are some criticisms that AJAX applications have broken some important browser features, including support for forward / back buttons.
This article first explains why the forward / back buttons and some other browser functions don't work properly unless those functions are explicitly incorporated into the AJAX application. Then briefly list how developers solve the above problems. Finally, we will take a detailed look at how the Backbase AJAX engine provides support for the forward / back buttons and other browser features.
Do AJAX applications need a back button?
AJAX promises to allow developers to use only standard browser technologies to develop web applications that have a better user experience and are highly interactive. This technology is often referred to as DHTML.
In the past, developers often had to choose between rich and reach; the former refers to a highly interactive interactive user interface, and the latter refers to a web browser that runs on all web browsers without additional installation mechanisms. Front terminal. AJAX application will make the foreground terminal both "rich" and "reach".
But what exactly is the meaning of an interface "rich"? And what is the meaning of an application "reach"?
The concept of "rich" is not easy to define, but it is easy to feel intuitively. If you see a "rich" interface, you will understand what a "rich" interface is. Desktop applications like Microsoft Office are a "rich" interface. A "rich" interface uses advanced UI control technologies such as Tabs and context menus. They provide a means of mutual progress, like drag-and-drop and highlighting of UI elements when they gain focus. Traditional browser applications are not "rich". They are limited to simple controllers, like Form, and interactions simply rely on clicking on a link to a new page. A look at Microsoft's email client shows the difference: Outlook is "rich" and hotmail is not.
AJAX applications are praised for their expressiveness, and Google's Gmail is a frequently mentioned example. Other AJAX applications made by Google, such as Google Suggest and Google Map. Microsoft's upcoming Web mail client, code-named "Kahuna," or Backbase RSS Reader also includes advanced controllers and interworking models. Take a look at Dan Grossman's list: Top 10 Ajax Applications, there are some exciting lists about the "rich" interface.
So I can conclude that AJAX applications clearly satisfy the concept of "rich". But does it satisfy "reach"?
In most basic forms of AJAX applications, if the interface runs in a web browser, the application is "reach". AJAX applications are based on a standard browser, so they can be accessed by a browser.
However, it is not enough to be understood by the browser. In his article Flash: 99% Bad, Jakob Nielson pointed out that Flash "undermines the basic interactive style of the web." When using WEB applications, end users expect a certain interaction style. The application needs to provide a traditional WEB interaction style and provide the following usability features:
. Must provide a "back / forward" button to allow users to browse web history
. Users can use bookmarks
. Deep links must be provided so that users can email them to friends or colleagues
. A "Refresh" button must be provided to refresh the current state, not obtained by re-initializing the application
. Developers can view source code by using "view source"
. End users can use "find" to search pages
. Search engines can index web pages and generate a deep link to search them
A look at the top 10 AJAX applications shows that most of the current AJAX applications do destroy the basic interactive style of the Web. In the next section, we will take a look at why many AJAX applications do this.
 
Why do AJAX applications often break the back button?
The web we know today is firmly based on the following three principles:
. Interface created using (D) HTML
. Client / server communication using HTTP
. Addressing with URIs
The above principles determine that the web applications we have have certain limitations, and AJAX applications make the interface richer by breaking through this limitation. As explained in my previous article: A Backbase Ajax Front-end for J2EE Applications. AJAX introduces the widely used Javascript (J in AJAX) to create rich UI interface controllers and interactions. AJAX also introduces asynchronous XML communication (A and X in AJAX). This is through the introduction of XMLHttpRequest objects to load new data and presentation layer logic without page refresh. However, the current AJAX model cannot locate how to handle URIs.
As a direct consequence of changing the use of (D) HTML and HTTP, AJAX applications destroy the back button and other elements that are the basic interactive style of the web. In the remainder of this article, I will explain how to fix this damage by processing URIs in the AJAX way. I will first explain why URIs are related to the interaction of traditional web applications.
In user terms, the state of the user interface has changed. The end user initiates a state change. The browser client handles the state change by sending a page request to the server (REST principle). The server generates a new interface state by sending a new page and new URIs to the client.
In short, each user interaction is handled in such a way that the loop through the server produces the following results:
. Generate a new page
. Generate a new URI
Because the browser records consecutive URIs into its history stack and displays the current URI in the address bar, the usability feature of the web is activated. In the address bar, users can copy the URI and send it to friends. When the user clicks the back button or pastes a URI from the email into the address bar, a loop to the server is triggered. Since the server is responsible for state management, the server can generate corresponding pages.
The biggest difference between AJAX applications and traditional web applications is that AJAX applications can handle user interaction without reloading the page. An example is loading data from a server via the XMLHttpRequest object. Using Javascript to handle client-side drag-and-drop is another example.
In the two examples above, the state change was not obtained by generating a new URI. Therefore, clicking the back button or refresh button does not get the desired effect, and there is no deep-link URI in the address bar.
In order to provide traditional web usability features, AJAX applications need to handle URIs clients just like traditional web applications. Therefore, AJAX applications need to do the following:
. When a client state changes, a URI is generated and sent to the client
. Save state when a new URI is requested by the client
If you do the two above, the browser's history will work, and the browser's address bar will display a URI that can be sent to friends.
Another difficulty is deciding when the AJAX engine should do those two things (for example, what state changes will result in a new URI). In traditional mode, each page refresh causes an URI update. In AJAX mode, every client event may generate a URI to the browser stack. Interaction designers and developers will decide what state changes make sense. New URIs are therefore generated only for those meaningful state changes.
I will summarize the client requirements for AJAX applications that need to provide web usability features:
Produce historical records
a. Save meaningful state
b. Generate the corresponding URI
c. Push the URI to the browser stack
2. Restore historical records
a. Detect URI changes
b. Maintain the state obtained from the URI
 
Basic design supporting back button in AJAX
In this section, we will discuss the basic steps to support the back button in an AJAX application. I will introduce some simple code to show the necessary steps. A more complete approach on how to implement cross-browser compatible back button support has been implemented. It is described in two articles written by my favorite MikeStenhouse (Content with Style) and Brad Neuberg (OnJava).
As shown in Figure 1, my simple example application has a selection box with two selection items: Year 1 and Year 2. Because of the purpose of this article, when the value of a selection box changes, we will record its history. This means that if the user selects Year 2 first, then clicking the back button will return to the previous selection.

                  Figure 1: A simple example with only one selection box
 
The beginning of this sample application is just some simple HTML code with some JS code for the getter and setter methods for the value of the select box:
 
We first deal with the first demand: a historical record of the status. As mentioned earlier, this requirement includes the following three parts:
1. Historical record
a. Save meaningful state
b. Generate the corresponding URI
c. Push the URI to the browser stack
I want the saved state to be every time the value of the select box changes, so I need to generate a new URI containing the state information of the select box.
To maintain adaptation to the standard Internet, I use fragment identifiers for URIs, which are described in IETF RFC 3986. "... The fragment identifier serves as an indirect reference to the client's original form and plays a special role in the information recovery system. The <...> fragment identifier is the part of the URI that is obsolete. Regardless of the URI pattern, the internal identification information of the fragment is The user agent is obsolete ... "
Using the fragment identifier, I was able to generate an "AJAX-URI" consisting of client and server segments, separated by "#" symbols.
JavaScript provides the window.location () method to update browser history and location URIs. In addition, you can access the fragment identifier directly through window.location.hash ().
Below the code snippet, you will see that I extend the code by handling the onchange event of the select box to update the history and using "AJAX-URI" to update the address bar.
 
As shown in Figure 2, each time the value of the selection box is updated, the browser address bar is updated. Please note: For IE, you need to use a hidden frame to get the same effect. Similarly, you can go to Mike Stenhouse or Brad Neuberg's article for full details.

             Figure 2: History stack updated when state changes
Now when the value of the select box changes, you have an event handler that can generate a new URI. The new URI uses fragment identifiers to store information to maintain the previous state. With it, let's look at the second requirement:
2. Restore historical records
a. Detect URI changes
b. Maintain the state obtained from the URI
In step 1, we updated the client's URI using the window.location.hash () method. This call did not cause the server to cycle and page refresh. I need to handle client URIs in an AJAX way.
First, I added a polling method to detect URIs in the browser history. Then register the pollHash () method in the page's onload () event, and then run it every 1,000 milliseconds.
The Polling method will call the handleHistory () method. This method will detect if the URI has changed since the last detection. I use a global variable expectedHash to do this.
The last part is used to determine whether the URI has changed, or because of the time processing of the selection box, or because the user clicked the back button. I did this by setting the expectedHash variable in the event handler of the select box.
 
I can conclude from my simple example how to record the state in the URI: push the URI to the browser's history stack, detect the change of address from the back button, and finally maintain the required state.
This example still lacks several features, such as:
. Support IE to use a hidden iframe
. More hard URIs (example runs only select boxes with less than 10 options)
. Register the initial state at the time of creation
It is not easy to fully handle all traditional web usability features compatible with all browsers under the requirements of a good robustness. An alternative is to use the built-in AJAX toolbox to support these features.
In the following sections, I will describe how to use the Backbase AJAX engine to provide these features. I refer to the Ajax forum on the Backbase DevNet to illustrate.
 
Case Study: AJAX Forum with Back Button and Deep Link
Backbase AJAX engine is a mature AJAX software package with rich traditional web features. Strong support for traditional web features is a feature of Backbase. Backbase DevNet includes 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.

Figure 3: Forum status with AJAX URI (click on the image to see a larger version of it)
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.

Figure 4: Forum status maintained by new browser window (click to enlarge)
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.

Figure 5: Forum status using the back button (click to enlarge)
 
 
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