Asp.net Ajax client programming-Ajax principles

In the previous article about ajax.netArticleI mentioned a concept-two-differentiation programming mode. From this point on, traditional WEB programming is server-side programming, and we work together with server development technology. Maybe you would say this is not the case. We are all using JavaScript to complete some necessary client functions (client authentication in ASP. NET supports many functions of the client )! However, not using JavaScript does not indicate that it is in the same status as Server programming. The concepts involved in server development do not exist in the client, for example, application. They are usually used to make up for functions that cannot be completed well in some Server programming modes, we just need to break it down to the client.

The emergence of Ajax has changed the existing understanding. Can the client be as important as the server development technology? A server is usually called"Program"The client is called" script ". Before the emergence of Ajax, few people were willing to admit that client development could be viewed as a "program", and now things have changed, ajax makes us realize that the client needs to be promoted to "program", at least as a part of the web program, instead of controlling the DOM elements and making a beautiful interface operation. Based on AJAX technology, it can be the same as data management, interface operations, and program-level management functions. The client library of ajax.net implements the concepts described above.

"The current application of the previous page. "

Let me first describe the classic process in the traditional web development model (no matter what technology is used as the basis for web development ).

1. Generally, a request is sent to the server by the browser.
2. The server receives this request, and the server executes the preparedCode. (It usually starts or reuses the "application" of a server ").
3. Finally, the execution result is sent to the client as a response (the response content is generally HTML in the broad sense ).
4. After receiving the response, the browser is responsible for displaying the response ). Now we can see the result (PAGE) in the browser ).

In the model described above, what do you know? If the above pattern is used, we really only need to care about what happened on the server side. If you give me a request, I will give you a response. What else do I need to do? At most, I use JavaScript on the client to provide the customer's visual functions. There is nothing wrong with it. What has Ajax changed? When I first came into contact with Ajax, I thought it was just an extreme usage of JavaScript and would not have any "profound" impact on WEB programming. However, it is not as simple as I think.

Let's take a look at how Ajax works.

1. If the page has been loaded, the page is filled with HTML code, JavaScript code, and CSS styles.
2. The user accidentally triggers a server submission when performing operations on the page.
3. In Ajax, the page is no longer refreshed, And the browser progress bar is not displayed. Ajax quietly initiates a request (asynchronous ).
4. When the server receives the request, it starts executing the server code and sends the result to the browser. What is the content sent? It is no longer HTML, but data.
5. When the data is returned to the browser, the browser can only automatically render HTML. What is the so-called "data? How do you know how to present it. This is probably where you are.
6. The data is actually received and processed by JavaScript code. Do you remember Dom? Can we use JavaScript to control Dom? You can imagine the following. Javascript receives data and operates Dom to render the data. This is also a difference between Ajax and traditional web. Browsers automatically render HTML in traditional Web environments, but not in Ajax environments. All rendering work can only be processed by JavaScript. 
7. Then the mysterious content is updated.

If you are a very careful person, you will get some key things from these two descriptions. Let me make it clear that the requests are the same (in essence, when we temporarily think they are the same) and then the response. Both give a response, but the content is different. The former must provide HTML text that can be interpreted by the browser, while the latter gets a response called "data ", it cannot be obtained by the browser and can only be processed by JavaScript.

Two key differences:

1. In traditional methods, initiating a request means that the content of the browser must be refreshed. The latter causes the request to be secretly sent.
2. In traditional mode, the received response is automatically displayed on the interface by the browser. The latter won't. Because all he gets is data, the rendering function is not completed by the browser but by himself.

The above two points lead to the two development modes destined to be different. Although it is not very different, you must not stick to the original development model.

The Ajax development mode is destined to require developers to pay more attention to the functions of the client, and even move more things originally done on the server to the client. If you need to develop reliable, efficient, and controlled code on the client, can you just use the original JavaScript programming method (which we often use?