A brief analysis of AJAX application scenarios

Ajax

Ajax Application Scenarios

1. Form-driven interaction

Traditional form submission, after the text box input, click the button, the background processing finished, the page refresh, and then look back to check whether the refresh result is correct. Using AJAX, after clicking on the Sunmit button, immediately asynchronous processing, and on the page quickly show the results of the update, there is no overall page refresh problem.

2. Deep-rooted tree navigation

The Deep cascading menu (tree) traversal is a very complex task, using JavaScript to control the display logic, using AJAX to delay loading deeper data can effectively reduce the burden on the server.

Most of our previous processing of cascading menus is this:

In order to avoid the overloaded pages that are caused by each operation on the menu, instead of using each call back to the background, all the data for the cascading menu is read out and written to the array, and then the rendering of the subset item is controlled by JavaScript according to the user's action, which solves the response speed, Do not overload the page and avoid sending requests frequently to the server. However, if the user does not operate the menu or only a part of the menu, the read data will become redundant data and waste the user's resources, especially in the context of complex menu structure, the large amount of data (such as the menu has many levels , every level of food and hundreds of projects), this abuse is more prominent.

If Ajax is applied in this case, the results will be improved:

When we initialize the page, we only read all the data from its first level and show that when a user operates one of the first-level menus, all data for the level Two submenu to which the current level of the project belongs is requested by Ajax to the back desk, and if you continue to request an item from the level two menu that is already rendered, And then to request all the data of all level three menus for the two-level menu item that you are working on, and so on ... In this way, take what you use, take as much as you can, there will be no data redundancy and waste, reduce the total number of data downloads, and update the page without overloading the entire content, only update the part that needs to be updated, relative to the background processing and overloading of the way to shorten the user waiting time, but also to minimize the waste of resources.

3. Fast communication between users and users

The most frustrating thing about being involved in the conversation is to have the user refresh the page over and over again to see if there is a new discussion. New responses should be displayed as quickly as possible, and Ajax is the best choice to free users from distracting refreshes.

4. Similar to voting, yes/no and other innocuous scenes

In a scenario like this, if the commit process needs to reach 40 seconds, many users will simply ignore the past and not participate, but Ajax can control the time within 1 seconds, so that more users will join in.

5. The scene of filtering and manipulating relevant data for data

Use filters for data, sorted by time, or sorted by time and name, switch filters, and so on. Any situation requiring highly interactive data manipulation should be done using JavaScript, rather than a series of server requests. After each data update, it takes more time to find and process it, and Ajax can speed up the process.

6. Normal text input prompts and automatic completion of the scene

Typing prompts in input forms such as text boxes, or automating them, can be an effective way to improve the user experience, especially if the automatically completed data may come from a server-side situation, Ajax is a good choice.

Ajax does not apply to scenarios

1. Some simple forms

Although form submission can get the most benefit from Ajax, a simple comment form rarely gets any noticeable improvement from Ajax. While some of the less-used forms are submitted, Ajax is not a helpful one.

2. Search

Some AJAX-enabled search engines such as start.com and live.com are not allowed to use the browser's Back button to view the results of a previous search, which is inexcusable for users who have developed search habits.

Now dojo solves the problem with an IFRAME.

3. Basic navigation

Using AJAX to do navigation within a site is a bad idea, why not put time on the system to make it better?

4. Replace a large amount of text

Use Ajax to achieve local refresh of the page, but if each part of the page changes, why not make a server request again?

5. Manipulation of the presentation

Ajax looks like a pure UI technique, but it's actually not. It is actually a technique for data synchronization, manipulation, and transmission. For a clean, maintainable Web application, it's a good idea not to use Ajax to control page rendering. JavaScript can be very simple to deal with Xhmtl/html/dom, using CSS rules can be very good expression of data display.

The problems that exist

1. JavaScript ajax engine, JavaScript compatibility and debug is a headache;

2.Ajax No refresh overload, because the page changes without refreshing the overload so obvious, so easy to bring trouble to users? D? D users are not sure whether the current data is new or have been updated; the existing solutions are: in the relevant location hints, data updates of the area design is more obvious, the data updated to user prompts, etc.;

3. The intermediate process cannot be bookmark. WORKAROUND: GoogleMaps by providing a "link to this page" solution on the pages. In addition, you can also resolve it by adding an invalid? ^ tag to the URL link, but it has not yet been validated.