Develop AJAX applications that retain the standard browser functions (1)

Ajax applications are widely praised for their rich functions, interactivity, and fast response capabilities. It can use the XMLHttpRequest object to dynamically load data, instead of loading new pages. As it was widely publicized and excited by many people, some comments pointed out that Ajax applications lost some important functions of the browser, including support for the backward button.
This article will first explain why Ajax applications cannot run unless they explicitly build the back/forward button and other browser functions. Then, we will briefly introduce how developers can solve these problems. Finally, we will see details about how the Backbase Ajax engine supports the back/forward button and other standard browser functions.
Do Ajax applications require a backend button?
Ajax promises that developers can create visually appealing and highly interactive Web Applications based entirely on standard Web browser technologies, typically DHTML.
In the past, developers had to provide rich functions, highly interactive and attractive user interfaces.) and easy access, clients can work in front-ends of all Web Browsers without installation) make a choice between the two. Ajax applications should be able to generate front-ends that are both "rich in functions" and "easy to reach.
But how can an interface be regarded as "rich functions", and how can an application be "easy to reach?
It is difficult to accurately define the meaning of "rich functions", but it is easy to intuitively realize that when you see an interface, you will know whether it is rich functions. Desktop applications such as Microsoft Office are rich in functions. You can use advanced UI controls such as tabs and context menus on a rich UI. This interface provides some advanced interaction methods. For example, drag-and-drop, and highlight the UI elements of interest. Traditional browser applications are not fully functional. They are limited to simple controls such as forms. interactions are mainly composed of click links to new pages. We only need to look at Microsoft's email client to see the difference between rich features and not rich features: Outlook is feature-rich, and Hotmail is feature-rich.
Ajax applications have been widely praised for their rich functions. Google's Gmail is the most representative example. Other Ajax applications developed by Google: Google Suggest and Google Map) microsoft's upcoming Web mail client named "Kahuna" and Backbase RSS Reader both contain some advanced controls and interaction modules.
As discussed above, Ajax applications obviously meet the "rich functions" standard. Is it "easy to arrive?
First, the most basic thing is that only the applications that run the interface in the Web browser are "Easy to get. Ajax applications are based on browser standards, so they can be accessed through a Web browser.
However, Web browser access is not enough. End users want to face specific interactions when using Web applications. Applications must follow the traditional Web interaction mode and provide the following available functions:

• The back and forward buttons can work properly so that end users can navigate to the history page.
• You can create bookmarks.
• Deep links are supported to ensure that end users can email this page to friends and colleagues.
• The refresh button can work properly to refresh the current status rather than reinitializing the application.
• Developers can use "View Source File" to view the source code.
• End users can use "Search" to search for pages.
• Search engines can index pages and create deep links to search items.

Most of the Ajax applications discussed previously did break the standard Web interaction mode. In the next section, we will discuss why many Ajax applications do this.

Why Ajax applications often make the backend button unable to work normally?
The Web is based on the following three principles:

• Use (D) HTML to define the interface
• Use HTTP to implement communication between the client and server
• Use URI for addressing

Ajax programming breaks through the limitations brought about by the above principles, making the interface functions richer. Ajax is widely used in JavaScript "J") to create rich UI components and interactions. Ajax also introduces Asynchronous XML communication "A" and "X"), that is, using the XMLHttpRequest object to import new data and representation logic without refreshing the page. However, the current Ajax model does not solve the problem of URI processing.
The Ajax application changes how HTML and HTTP are used, the direct result of this change is that other elements of the basic interaction between the backend button and the Web cannot work normally. In the rest of this section, I will explain how to solve the above problem by processing the URI in Ajax mode. First, let's look at how URIs in traditional Web applications interact with users.
Technically, user interaction refers to a change in the user interface status. The status change is initiated by the end user. The browser client sends a page request to the server to handle the REST rule of status change ). The server sends a new page and URI to the client to generate a new interface status.
In short, each user interaction is handled through a server round-trip that will result in the following results:

• Generate a new page
• Generate a new URI

These Web functions can be used because the browser records continuous URIs in its history stack and displays the current URI to end users in the address bar, you can copy the URI in the address bar and send it to a friend. When you click the back button or paste an email URI to the address bar of your browser, a round-trip to the server is triggered. Because the server is responsible for status management, it can generate corresponding pages.
The main difference between Ajax applications and traditional Web applications is That Ajax applications can process user interactions without page reloading. For example, you can use the XMLHttpRequest object to load data from the server, or use JavaScript to process the drag-and-drop client.
In the preceding two examples, the status changes, but no new URI is generated. Therefore, clicking the back button or refresh button will produce unexpected results, and there will not be a deep-link URI in the address bar.
To provide traditional Web availability functions, Ajax applications need to process URI clients in a way similar to servers that process traditional Web applications. Ajax applications need to implement the following functions:

• When the client status changes, a URI is generated and sent to the browser.
• When the browser requests a new URI, the status can be re-created.

After the above functions are implemented, the browser's history can work normally, and the browser's address bar can display the URI. Of course, you can also send it to friends.
There is another difficulty here, that is, how to determine when the Ajax engine needs to implement the above functions, for example, when the status change requires creating a new URI ). In the traditional mode, each page refresh corresponds to a URI update. In Ajax mode, each client event adds a new URI to the browser stack. Interaction designers and developers will have to decide which state change is meaningful. A URI is generated only for meaningful state changes.
The following is a summary of the functions that Ajax applications that provide Web functions need to implement on the client:

• Create history
  • Save meaningful status
  • Generate the corresponding URI
  • Add this URI to the browser stack.
• Restore History
  • Detect URI changes
  • Re-create status through URI

The basic design idea of supporting the back button in Ajax
In this section, we will discuss the basic steps required to support the back button in Ajax applications, and provide simple sample code to illustrate the steps required.
As shown in simple example 1, there will be a selection box in the interface, which has two values: "Year 1" and "Year 2 ". For this program, we will track the history when the selection box value changes. This means that you can select "Year 2" and then click the back button to go back to the previous selection.

Figure 1. Simple sample program with a selection box

The sample program is initially a simple HTML form with JavaScript getter and setter Used to select box values:

We will first implement the first requirement: Create a historical record of the status. As we mentioned earlier, this requirement involves the following three steps:

• Create history
  • Save meaningful status
  • Generate the corresponding URI
  • Add this URI to the browser stack.

We want to save every change in the selection box. Therefore, we will create a new URI that contains the status information of the Selection box.
To comply with Internet standards, we will use the fragment identifier section of the URI. According to ietf rfc 3986, As the main form of indirect reference by the client, the fragment identifier plays a special role in the information retrieval system ,〈...... > The fragment identifier is separated from the rest of the URI before being unbound from the reference. Therefore, the identity information in the fragment itself is discarded only by the user agent, regardless of the URI scheme ......".

Using the fragment identifier, we can create an "Ajax-URI". The client and server are separated.
JavaScript provides the window. location () function to update the browser's history and address through URI. In addition, we can use window. location. hash () to directly access the fragment identifier.