Speak with the truth! AJAX application Development Seven Deadly Sins

Ajax| Program

AJAX bandwagon is a good place to be. It brings you faster, more efficient, more dynamic applications. But it also has its own flaws.

At the junior level, having some common sense seems to be able to avoid these flaws, to some extent, indeed. But from the source of DHTML, Ajax applications are riddled with structural differences. No matter how much common sense you have in your application development work, it is also good to learn from the mistakes that others make. We call these errors "seven capital offences", but they do not represent all the errors.

In fact, before you commit these fatal mistakes, you may have made some minor mistakes first. So we start from here. This is a mistake that everyone can make. How common these bugs are, Google search, and you'll find most of the bugs.

Seven Misdemeanor cases

1. Misuse of the Back button-this is a mistake that everyone will make. The Back button has become a user's expectation in many Web applications. Many novice Ajax developers use the back button for a variety of reasons when developing AJAX applications. First, JavaScript is not the friendliest language for it; second, Ajax design requires a new way of thinking.

"Backwards" for Ajax developers is clearly not the best option. "Back" is a feature you use to update pages, or more often, when you need to "undo" in certain situations. Be aware of these before coding, or you may repeat work.

2. Forget to tell the user what's happening-ajax part of the work principle is that it does not use the regular Web user interface loader. Therefore, you need to explicitly design some visual cues to make the user aware of what is happening.

3. Ignore links-This is also the standard error of Ajax: Leaks are links to URLs that external users can clip. How many times have we copied a URL link and sent it to someone else? When you use Ajax, the only way to provide your users with URL links is to manually provide them. Why? Because in an AJAX program, the server does not provide this page that JavaScript dynamically generates! Do not overlook the most common features of this Web application that your users may be interested in. Now that the server doesn't support it, you have to do something to provide the user with URLs.

4. Replace control with content control-if you are looking for dynamic content control, a breakthrough in traditional client-server interactions is a good thing for you. But it's also a sin: it's true that when you rewrite the content of a page in an exact position to adjust the user's interactive experience, it's really good to control, but it also makes your page incomplete. Typically, we focus on one part of the page and forget that the server does not refresh the page. This can lead to messy pages, reduced user experience, and an outdated page when they look at the page! Put your attention on the whole page; Make sure that the contents of the dynamic page are updated.

5. Tired Spider –ajax advantage is that no need to reload can provide a large number of text on the page; The drawback of Ajax is the amount of text that can be provided to a page without reloading. If the application is set to search engine friendly, then you can imagine what will happen. Whatever appears on the page, be sure to embed enough text on the top to play for the spiders.

Generated garbled text-ajax does not support many character sets. This is not about the limitations of life and death, but forgetting it can produce real problems. The most basic character set is UTF-8. Regardless of what JavaScript sends, don't forget to encode correctly, and set the server-side character sets based on the content.

There is no hint for users who use browsers that do not support JavaScript--some browsers do not support JavaScript, and users cannot understand what is happening. Please provide them with tips.

To be honest, most of them are common sense problems. The real problem is easy to overlook.

Create a memory leak-anyone who has long been involved in development is aware of circular references and is aware of the hazards they bring to memory management.

The JavaScript used by Ajax is the language of memory management. This means that JavaScript has built-in packet collection capabilities, so it is able to extract variables that no longer have reference paths to use and reassign the memory used by those variables.

This is good as a basic principle of work, but you can't rely on this feature to implement your memory usage optimization as the model object and the viewing element are referenced to each other, because of these circular references. In principle, the object is zero, then the element is zero, but if this is the backward reference from the element to the object, the packet collector does not move the objects.

Now, the problem is that in the file object model, the DOM nodes in any file tree may be referenced by other elements in the tree, whether or not they are referenced by other objects! Therefore any object that is annotated in the packet collector and referenced backwards by the DOM node must be empty in this direction. Otherwise, its memory will always be in the allocated state.

Do not understand the meaning of "asynchronous"-asynchronous is easy to make users unfamiliar with it nervous. But if the Web applications you design for these users belong to a desktop application, they certainly don't feel uneasy. This is a critical design point. Most Web application features are very similar to desktop replicas. But in Web applications, users expect this illusory feature to cause them to be completely different.

Users have very different biases and expectations when dealing with web browsers, and they don't behave like that in desktop applications. Therefore, while the frequent response between pages and servers can be very good and efficient, pages can revise themselves at the same time, but this will make the user dizzy. Therefore, you need to follow the two rules, taking into account every change that goes into the user's vision: if it is not an urgent update for the user, make the upgrade more benign and not move; If the update is important to the user's interaction with the application, the update is clear and obvious.

Keeping servers in the dark-client-server communication is a big problem, not previously. Previously, server-side applications knew all about the situation and were able to see the full picture: Each exception, each reload, each event could be seen and recorded, and of course the server knew what was happening to the client, as the server would record everything on the screen.

This is not the problem with Ajax applications. When an event occurs, these events are independent of the server, that is, when the client has a problem, the server side does not immediately know. Discovering and documenting the events and exceptions that occur at a certain location enables the server to track issues that require intervention as quickly as possible.

Use get lazy-get to retrieve data again; Post is used for get settings. Don't use get when it's inappropriate, even if you think it's harmless. A get operation changes state, and a link that changes the state is confusing to the user; Most of the links are considered to be navigation, not functionality.

Incompatible data type--javascript is not part of the. NET Framework framework. Although this is really sad, it presents us with a problem we might encounter: determining that JavaScript can understand the type of data on its platform, and vice versa. NET or the other is so. There may be a variety of converters that you need to find out. For example, the Ajax.NET Pro database provides converters that can convert. NET and JavaScript object symbols.

Some applications do not know when to turn off--no need to refresh the content of the page to dynamically generate without closing time would be very bad.

How many pages have you seen that are longer than the proceedings of the United States Congress? If the Web page extends indefinitely, it will be a nightmare for users, as long as you think about what users will think of the apps that never stop. Let your network applications have dynamic effects, but must be within the limits of what is feasible.

Keep your javascript away from your dom-remember that Ajax is built on the model-vision-control (MODEL-VIEW-CONTROLLER) structure. Please take this seriously. JavaScript belongs to the model level, the DOM is visual, and the controller is their marriage counselor. Make sure your network files are independent of JavaScript (which is good for users who don't support JavaScript)--except that the content itself is meaningful and operable only when the user is using JavaScript. In this case, the content is created with JavaScript.