In the process of developing AJAX programs, many people will make some common mistakes. Some mistakes may endanger the functions and performance of the AJAX program, causing all the advantages of the AJAX program to be lost. Here the author will introduce to you the seven deadly sins that you need to pay attention to when developing AJAX programs.
AJAX is a good thing, it allows developers to build more dynamic applications faster and more efficiently. But it also has its own shortcomings.
At first glance, it might seem that a bit of common sense would prevent these pitfalls, and to some extent, it does. But compared with its rival DHTML, the architecture of the AJAX program is completely different. No matter how much common sense you have in your application development efforts, you should learn from the lessons of those who have come before you. In this article, we refer to these errors as the "Seven Deadly Sins," but they are not representative of all errors.
Before we learn about the seven fatal mistakes in AJAX development, let's take a look at seven less serious mistakes. Everyone makes these mistakes. Do a Google search and you'll see how common these errors are.
seven misdemeanors
1. Abusing the back button - Many people make this mistake, and the back button has become a must-have in many web experience programs. Many novice AJAX developers add the back button to their AJAX programs for various reasons, but find that the back button affects program functionality. This is mainly because Javascript is not a very user-friendly programming language. Secondly, developers have to relearn the development ideas of AJAX.
For those new to AJAX, it is not easy to accept the idea that the back button is not a good solution. When we are at the refresh point of the page, or when we need to use the "Undo" function, we can consider the "back key". But you must think twice before coding, otherwise repeated refreshes will easily occur.
2. Not informing the user of the results of the operation - Part of how AJAX works is that it does not use the usual web user interface loader. Therefore, you need to design some visual cues so that users understand what is happening.
3. Overlooked links - This is also a standard AJAX mistake: leaving out a URL link that external users can cut and paste. We've all copied a URL and sent it to someone else. When we use AJAX, we can only provide links to others through pure manual input. Why? Because in AJAX applications, the server does not provide this page automatically generated in Javascript. Don't overlook this most common feature in web apps that your users might be interested in. Please take a moment to provide the user with the URL address, as the server does not provide one.
4. Use content control instead of page control - If you are looking for dynamic content control, then AJAX application's breakthrough in the traditional client-server interaction method can be a great gift for you. However, this also has its own drawbacks: while you do have great control over rewriting content at a precise location on the page to adjust the user's interaction experience, you may end up with an incomplete page.
In many cases, we focus on processing a certain part of the page and forget that the server will not refresh the page. This can lead to cluttered pages and a poor user experience: when they view the page they may be looking at an outdated page. Please keep an eye on the entire page; make sure any page with dynamic content is updated.
5. Tired spiders--The advantage of AJAX lies in the large amount of text that can be provided to the page without reinstalling; the disadvantage of AJAX also lies in the large amount of text that can be provided to the page without reinstalling. If an app is designed to be search engine friendly, you should be able to imagine what could happen. No matter what happens on the page, be sure to put plenty of solid text at the top and let the spiders have fun.
6. Garbled characters - AJAX cannot support multiple character sets. This is not a life or death limitation, but forgetting this can lead to real problems. The most basic character set is UTF-8. No matter what charset your Javascript sends, don't forget to encode it correctly and set the server-side charset based on the content.
7. No prompts are provided for users who do not support Javascript - some browsers do not support Javascript, and these users cannot understand what is going on. Please give them some tips.
The above are some errors that are easy to find. The real problems are easily overlooked.
seven deadly sins
1. Allow memory to overflow - Anyone who has been engaged in development work for a long time knows what circular references are and understands the harm that circular references bring to memory management. Javascript used by AJAX is a memory management language. In other words, Javascript has a built-in packet collection function, so it can extract variables that are no longer used by reference paths and reallocate the memory used by these variables.
Anyone who has been working in development for a long time knows what circular references are and understands the dangers they bring to memory management. Javascript used by AJAX is a memory management language. In other words, Javascript has a built-in packet collection function, so it can extract variables that are no longer used by reference paths and reallocate the memory used by these variables.
Now, here comes the problem: in the file object model, any DOM node in the file tree may be referenced by other elements present in the tree, regardless of whether it is referenced by other objects! Therefore, any object marked in the packet collector as being referenced back by a DOM node must be zero in this direction, otherwise its memory will remain allocated.
2. Don’t understand what “asynchronous” means – The word asynchronous can easily make users unfamiliar with it feel nervous. But if the web app you design for these users is a desktop app, they won't be upset. This is a crucial design point. Most web apps function very similarly to their desktop counterparts. But in web applications, users expect this illusory quality to lead to them being completely different.
Users have very different biases and expectations when dealing with web browsers than they do with desktop applications. So while frequent responses between the page and the server would be nice and efficient, with the page revising itself simultaneously, it would make the user dizzy. Therefore, you need to follow two rules and consider every change that comes into the user's visual range: If the update is not urgent for the user, then make the upgrade gentle and not transfer; If the update is not urgent for the user, The interaction of the application is very important, so updates should be clear and obvious.
3. Make the server blind - the reduction of communication between the client and the server is a big problem, which was not the case before. In the past, the server-side application knew everything and could see everything: every exception, every reload, every event could be seen and logged, and of course the server also knew what was happening on the client, because the server What is displayed on the screen will be recorded.
This is not the case in AJAX applications. When events occur, these events are independent of the server. That is to say, when there is a problem on the client, the server does not know immediately. Discover and log client-side events and exceptions in a location that enables the server to track down problems that require intervention.
4. Use GET to be lazy - the function of GET is to retrieve data; the function of POST is to set up GET. Don't use GET inappropriately, and don't even try it if you think it's harmless. GET actions change state, and links that change state can confuse users; most believe links are for navigation, not functionality.
5. No monitoring of data types - Javascript is not part of the .NET framework. Although this is a bit sad, it does illustrate a problem we may encounter: making sure that Javascript understands the data types on the platform it is running on, and vice versa for .NET or other. There may be multiple conversions and you need to do them one by one. For example, the Ajax.NET Pro library provides converters that convert .NET and Javascript object notations.
6. Some programs cannot be closed - dynamic generation of content without refreshing the page would be very bad if there is no closing time. How many Web pages hav How many web pages have you seen that are longer than Hansard of Congress? If the web page extends indefinitely, it will undoubtedly be a nightmare for users. Just think about what users will think of applications that never stop. Make your web app dynamic, but within the limits of what's feasible.
7. Make Javascript and DOM independent of each other - remember that AJAX is based on the "Model-View-Controller" (Model-View-Controller) structure, please take this seriously. Javascript belongs to the model layer, DOM belongs to the visual layer, and the controller is the marriage consultant that connects them. Make sure your web files are independent of Javascript (so they are more useful for users who don't support Javascript) - unless the content itself is only meaningful to users using Javascript. In this case, use Javascript to create the content