AJAX + ASP. NET solves the problem of waiting for the webpage to open

I. Preface
People have to wait. In fact, users generally get bored when they wait for more than 200 milliseconds to operate their computers. This may be a problem when your web-based application uses a process that takes many seconds or even minutes. Obviously, you can't just create a progress bar dialog box or wait for the cursor to finish all the work.
Fortunately, ASP. NET provides different solutions to deal with such time-consuming processes-depending on the required interaction level and the complexity you are willing to handle. This article describes the problem through a sample application and runs it in two ways: one is simple query technology, another method is to use a more advanced AJAX solution.
Be vigilant. Some Incorrect methods have been found in the. NET Framework. One of them is IAsyncHTTPHandler. At first glance, it seems to be helpful for long web page requests. However, this asynchronous HTTP processor is designed to release the processor-although some tasks on a page require time but no CPU. A good example is to send a Web request in the middle of a page. In this case, the asynchronous HTTP processor is very efficient.
Ii. Problems
In this article, I will discuss a different question. In this example application, I created a page for reporting the current temperature, wind level, and other weather information for five different airports. It takes about five seconds for a Web service to obtain each item of data. Therefore, if I have this page 1 run, it takes about one minute before the server returns a page-this is unacceptable for any user.

Figure 1. Waiting: the initial sample application takes about one minute to load the page.

The corresponding HTML of this time-consuming page is displayed in List 1.
The page load event Code creates a dataset for the data grid. Then, quickly process multiple airports and call the web service to obtain data. Then, this method fills the data from the web service to the dataset and attaches it to a grid control (see figure 2 ).

Figure 2. Basic: the Web Service of the example application executes a simple weather condition query.

The WSDL for this web Service is http://www.capeclear.com/airportweather.wsdl. It defines many different methods and I will only use one of the getSummary methods-it returns a data block that includes the location of the airport, sky conditions, wind speed, visibility, and even more.
In this way, even a single server request consumes more time than a single page retrieval. Another option is to run a thread on the background to obtain data, and the frontend page continuously monitors the output of the thread.
Iii. Thread Solution
Thread solutions provide users with a cleaner experience-because they can be updated periodically. The response here is easy to prepare. Although the processing in the background may take some time, it can be returned immediately as a response.
To process this thread system, I will use two classes and one interface. JobHandler singleton is responsible for maintaining an object set-it implements the IJob interface. This JobHandler manages system threads. Each time a job is added, a new thread is created, and the Start method of the job is called in a new thread. An ID string used for subsequent query is returned.
The corresponding UML of the Job system is shown in figure 3.

Figure 3. This screen snapshot shows the corresponding UML of the Job system.

WeatherJob is an Ijob implementation-it is responsible for querying weather from a specified set in the airport and filling in a DataSet containing weather reports called Data.
The corresponding code of JobHandler singleton is displayed in List 2. For more information, see download source code. The only interesting thing is the AddJob method, which creates a new thread for the job and calls the Start method.
The interfaces for these jobs are displayed in list 3. The constructor creates a data set for the job. In addition, the Start method calls a WEB request through each airport and stores the returned data in the dataset.

Iv. query Solutions
The first solution to weather monitoring is to use queries. Therefore, the page will send data back to itself every two seconds. The request starts on the first page. After that, the page will monitor the output of the weather work by capturing the working data and transmitting it to the data grid on the page. The relationship between browsers, WEB servers, and threads is shown in Figure 4.

Figure 4. Query: the query HTML solution shows the relationship between browsers, WEB servers, and threads.

For details about the HTML displayed on the query page in list 4, see download source code ). The interesting part is the script block inside the tag refreshScript. When the label is visible, the script will be executed to load the page for two seconds and then resubmit the form-this will update the data in the grid.
The code behind the query HTML is displayed in List 5. For more information, see download source code ). The important code here is in the page_load method. If the request ID stored in the hidden table field is null or blank, this is the first time the page is loaded. When the page is loaded for the first time, the ID of the job is created and placed in a hidden form field.
In two seconds, the Javascript will be activated and the page will be reloaded. The request ID approaches the hidden input field for the second time, and the Code uses the specified ID to find the job and uses the data to fill the data lattice.
V. AJAX Solution
Page reload in Internet Explorer will result in an audible mouse button and a screen flash when the page becomes blank and waiting for reload. It may be annoying if it occurs every two seconds. AJAX provides an option to dynamically update a page (see figure 5) only when one page is loaded and the Javascript request in the page is updated every 500 milliseconds ).

Figure 5. AJAX solution: Javascript updates page data in the background every 500 milliseconds.

The HTML section of the AJAX page is displayed in list 6. For details, see the download source code.) Most of the Code is Javascript. This Javascript first activates addField call-it adds different fields returned from the server in XML format. This startup page starts the first request to the server. GetData starts a request by calling createHTTPRequest. This function uses cross-platform code to construct HTTP request objects.
The HTTP request is asynchronous. When the request is complete, call the handleResponse function-this function analyzes the XML and creates some new HTML for the data table-This HTML will be placed in the "grid" label.
The code behind this page is displayed in list 7. In the code, page_load starts the job and uses the URL on the data request page to set hidden input fields.
The get_data.aspx page uses a request ID and returns an XML description of the current data set. The code on this page is shown below:

// Get_data.aspx <% @ Page language = "c #" Codebehind = "get_data.aspx.cs" AutoEventWireup = "false" Inherits = "background. get_data" %>

Obviously, the background code is more important in this case. This code is displayed in List 8. For details, see the download source code.-It first sets the response content type to "text/xml ". If the AJAX Code does not exist in the browser, an XML document will not be generated from the response. After that, the code gets the request and requires DataSet to generate the XML. Then it slightly changes the XML response to add the "done" field-this is used to tell the customer whether the request has been completed.
When the page is started for the first time, it looks 6.

Figure 6. Still query: the screen snapshot shows the AJAX page that is still in the query.

When the request is complete, the browser will look like 7. When using AJAX solutions, remember that when creating code, you are setting the minimum browser requirements-not all browsers can create HTTP requests. In fact, it can only be implemented by the nearest browser. Ideally, your solution should provide both query version support for older browsers and AJAX version support for new browsers.

Figure 7. Finished: the screen snapshot shows the completed AJAX page.

Vi. Summary
In the most favorable circumstances, the thread may also have problems. In this case, the thread may be more difficult to monitor-because it runs on the server's background. Of course, even if no Web Client is monitoring it, the request may continue to run. If this is a problem, you should set a timestamp for the WEB monitoring code in a threaded process. If the thread process finds that it has not been watched for a while, it can cancel it.
There are several methods in. NET to implement background processing, and the thread method in this article is only one of them. You can also use ASP. NET cache to work, or even create a real background processing process. By using these different technologies, you can turn a very time-consuming processing wait into a rich feedback user experience related to process processing.
(