ajax| Standard | program | browser
Ajax applications have been widely praised for their richness of functionality, interactivity, and rapid responsiveness. Instead of loading new pages, it can dynamically load data using the XMLHttpRequest object.
While it's hype and excitement for many people, there are comments that Ajax applications have lost some of the key features of the browser, including
move back .button is supported.
This article will first explain why you won't be able to run in an AJAX application unless you explicitly build the back/forward buttons and other browser features. Then, we'll briefly explain how developers can address these issues. Finally, we'll see details on how the Backbase Ajax engine supports the back/forward buttons and other standard browser features.
does the AJAX application need a back button?
Ajax promises to enable developers to create visually appealing, highly interactive Web applications based entirely on standard Web browser technologies (usually DHTML).
Previously, developers were forced to
feature-Rich(highly interactive, attractive user interface) and
easy to reach(There is no need for a client installation to work at the front end of all Web browsers) and make a choice between the two. Ajax applications should be able to produce both "feature-rich" and "easy to reach" front-end.
But how can an interface be considered "functionally rich" and how is an application "easy to arrive"?
It's hard to define the meaning of "feature-rich" precisely, but it's easy to intuitively realize that when you see an interface, you know it's not a feature-rich one. Desktop applications like Microsoft Office are feature-rich. The feature-rich interface uses advanced UI controls such as tabs and context menus. Such an interface provides some advanced interaction methods. For example, drag-and-drop, highlight UI elements for attention, and so on. Traditional browser applications are not feature-rich. They are limited to simple controls such as forms, and the interaction consists primarily of clicking links to new pages. Just look at Microsoft's email client to see the difference between rich and functional: Outlook is functional, and Hotmail is not very functional.
Ajax applications have been widely praised for their rich functionality. Google's Gmail is one of the most representative examples. Other Ajax apps Google has developed (Google suggest, Google Map), Microsoft's upcoming web mail client named "Kahuna" and Backbase RSS reader include advanced controls and interactive modules.
From the previous discussion, it can be said that Ajax applications clearly meet the "feature-rich" standard. So is it "easy to arrive"?
First of all, the most basic is that only the interface in the Web browser to run the application is "easy to reach." Ajax applications are browser-based, so they can be accessed through a Web browser.
However, it is not enough to access the Web browser alone. End users want to be faced with a particular interaction when using a Web application. Applications need to conform to traditional web interactions and provide the following available features:
- The back and Forward buttons work correctly so that end users can navigate to the history page.
- Users should be able to create bookmarks.
- Support for deep links to ensure that end users can send this page to friends and colleagues by e-mail.
- The refresh button works correctly to refresh the current state instead of reinitialize the application.
- Developers can use "view source" to see source code.
- The end user can use Find to search the page.
- Search engines can index pages and create deep links to search items.
Most of the AJAX applications discussed earlier did break the standard web interaction. In the next section, we'll discuss why many AJAX applications do this.
Why do AJAX applications often make the back button not work?
What we call the Web is based on the following three principles:
- Use (D) HTML to define the interface
- Using HTTP to implement communication between the client and the server
- Using URIs for addressing
Ajax programming has broken through the restrictions imposed by the above principles, making the interface more rich. Ajax uses JavaScript ("J") extensively to create feature-rich UI components and interactivity. Ajax also introduces asynchronous XML traffic ("A" and "X"), which means using the XMLHttpRequest object to import new data and presentation logic without refreshing the page. However, the current AJAX model does not solve the problem of how to handle URIs.
Ajax applications have changed the way that (D) HTML and HTTP are used, and the immediate result of this change is that the back button and other elements of the web's basic interaction do not work properly. In the remainder of this section, I will explain how to solve the above problem by handling URIs in an AJAX manner. First, let's take a look at how URIs are associated with users in a traditional Web application.
From a technical standpoint, user interaction refers to a change in the state of the user interface. State changes are initiated by the end user. The browser client handles state changes (rest rules) by issuing page requests to the server. The server will send a new page and a new URI to the client to generate a new interface state.
Simply put, each user interaction is handled by a roundtrip server that results in the following:
- Generate a new page
- Generate a new URI
These web features can be used because the browser records a contiguous URI in its history stack and displays the current URI to the end user in the address bar, and the user can copy the URI through the address bar and send it to a friend. A round-trip to the server is triggered when the user clicks the Back button or pastes a URI from the e-mail message to the browser's address bar. Because the server is responsible for state management, it can generate the appropriate page.
The main difference between an AJAX application and a traditional Web application is that an AJAX application can handle user interaction without a page reload. For example, loading data from a server through a XMLHttpRequest object, or using JavaScript to process a drag-and-drop client.
In the two examples above, the state changed, but no new URI was generated. Therefore, clicking the Back button or the refresh button will produce unexpected results, and there will be no deep linked URI in the address bar.
To provide traditional web-available functionality, AJAX applications need to process URI clients in a way that is similar to a server-handling traditional Web application. Ajax applications need to implement the following features:
- When the client state changes, a URI is generated and sent to the browser
- The state can be recreated when the browser requests a new URI.
After you implement the above features, the browser's history will work, the browser's address bar can display the URI, of course, you can send it to friends.
Another difficulty here is how to determine when the Ajax engine needs to implement the above functionality (for example, which state changes need to create a new URI). In a traditional pattern, each page refresh corresponds to a URI update at a time. In AJAX mode, each client event adds a new URI to the browser stack. Interaction designers and developers will have to make a decision about which state change makes sense. You need to generate a URI only for meaningful state changes.
Here's a summary of the features that AJAX applications that provide Web-enabled functionality need to implement on the client side:
- Create history
- Save a meaningful state
- Generate the appropriate URI
- Add this URI to the browser's stack
- Restore history
- Detecting changes to URIs
- Recreate state through URI
[1] [2] [3] [4] Next page
