ASP. NET 2.0 implementing AJAX Web development (1)

This article has three purposes. First, I want to provide an advanced overview of an AJAX-style application. Secondly, I want to describe the asynchronous callback mechanism of ASP. NET 2.0 in detail. Finally, I would like to look forward to the future improvement of tools and frameworks for building AJAX-style applications.
In summary, AJAX-style Web applications show the following features:
• Asynchronous requests to the Web server-when the user waits for a response from the Web server, the browser user interface is not blocked, but can continue to respond to user interaction.
• Highly dependent on browser-based logic written in JavaScript-the latest W3C DOM improvements and standardization provide support for dynamic client UI updates.
• XML-based data exchange between browsers and Web servers-XMLHttp Objects make it possible to communicate with Web servers without the need to reload pages.
The biggest difference between an AJAX application and a traditional Web application is that each user interaction does not send every HTTP request to the Web server. Instead, the browser-based logic implemented by JavaScript controls the control, and then the control determines whether to process requests locally or make asynchronous calls to the server. Once the asynchronous call to the server ends, the client logic immediately Updates relevant parts of the UI. This method has the following advantages:
• Richer user experience. For example, when a Google Map user is dragging a map in one direction, the system sends an asynchronous request to the server in the background, and the result is that the user can continue to drag the map after the screen boundary is exceeded. In this way, new images are available when you move the map further. This leads to a faster response.
• Since the call status to the server over XMLHttp is not lost, AJAX applications can avoid re-generating the UI every time.
• More logic is on the browser side, which reduces the number of back-and-forth requests to the Web server and comprehensively improves the potential of the system.
Despite so many advantages, AJAX-style applications still have some shortcomings. For example, it is difficult to develop AJAX-style applications because of the lack of a set of frameworks similar to Windows MFC toolkit UI classes) and IDE debugging, visual design, and so on. In addition, AJAX-based development requires a person to have at least two languages: DHTML and JavaScript ). In addition, it takes longer to encode an AJAX-style application because it requires additional tests to support multi-browser versions and types. Finally, as the JavaScript-based source code is accessible to end users, security analysis becomes very important during development.
Fortunately, the emergence of tools such as Atlas, AJAX. NET, and Google Maps APIs provides better support for building AJAX-style applications in the future. Next, we will discuss the development history of supporting technologies for building AJAX-style applications and what we expect from the latest toolkit Atlas.
Let's first discuss XMLHttp objects. This object was initially introduced by Microsoft and will be implemented on other platforms, including Mozilla and Apple's Safari browsers. XMLHttp supports asynchronous requests to the Web server, which allows the client to call the Web Server Based on JavaScript logic without the need to reload the entire page.
In other words, it is entirely possible to interact with the Web server in the background without causing the whole page to be reloaded.
XMLHttp objects are directly used. For simplicity, let's only consider the specific IE syntax. In fact, the implementation Syntax of XMLHttp in other browsers is similar to that discussed here.

Request = new ActiveXObject ("Microsoft. XMLHTTP "); If (request) {request. onreadystatechange = CallbackHandler; Request. open ("GET", URL, true ); Request. send (); } Function CallbackHandler (){ If (request. readyState = 4) & (request. status = 200 ){ String response = request. responseXML; // Update the UI } }

In the code snippet above, the first step is to instantiate the Microsoft. XMLHttp class. Step 2: Set the attributes of the XMLHttp instance we just created, including the address of the callback function that will be controlled when the XMLHttp request is complete. We need the address of the callback function for asynchronous calls to the server by setting the third parameter of the open Method to true. During the implementation of the callback function, we perform additional checks to ensure that the request is complete.
As you can see from the sample code above, using XMLHttp objects in an independent way is quite simple. However, it is difficult to integrate XMLHttp into other parts of the HttpPage lifecycle-for example, how to ensure that method calls on the server can access the status of other controls on the page? To correctly initialize the status of these controls, the server-side callback process requires an HttpPage lifecycle similar to the callback process. Another challenge for using XMLHttp objects directly is that as developers, we need to consider different browser types. Fortunately, ASP. NET 2.0 provides a reusable mode that makes access callback very easy. Note that several controls, including the GridView and TreeView, are released along with ASP. NET 2.0, all using the callback mechanism.
Let's take a look at the server implementation principles. First, define a new interface IcallBackEventHandler on the server side. This ICallBackEventHandler interface is required for any ASPX page (or controls that intend to support client callback. The ICallBackEventHandler interface defines a method called RaiseCallbackEvent. This method uses a string type parameter and returns a string.

On the client side, a special JavaScript function needs to be called to initialize the callback function. You can call ClientScriptManager. GetCallbackEventReference to obtain a reference to this special JavaScript function. The call to GetCallbackEventReference generates a callback reference. When calling this callback function, you only need to pass a string type parameter. This is consistent with the RaiseCallbackEvent signature on the server. This is what you need to do to establish a callback mechanism on the client. The implementation of the RaiseCallbackEvent method from the client callback function hook up to the IcallBackEventHandler interface on the server is completed by the framework.

The special JavaScript Functions previously mentioned in the initialization callback mechanism use the other two parameters _ CALLBACKPARAM and _ CALLBACKID) as feedback data, they represent the string parameters passed to the caller and the Control ID. On the server side, ASP. NET detects the existence of the other two parameters and routes requests to the appropriate controls. This will cause the RaiseCallbackEvent method on the target control to be called. To solve the initialization problem of the control on the page mentioned above, ASP. NET provides a simplified version of HttpPage lifecycle during a service callback at runtime. This cycle includes a specific stage of page initialization, observation status loading, page loading, and callback function event processing. Once the callback function event is processed by the control, other stages of the HttpPage lifecycle will be skipped.
To help you better understand the callback mechanism of ASP. NET 2.0, the release package contains a simple progress bar control, which relies on callback to determine the status of a task determined by the server. The following list 1 shows the code of the ProgressBar control. To support the client callback function, this control implements the ICallbackEventHandler interface. For demonstration purpose, the RaiseCallbackEvent method simply finds a counter stored in the session, adds 1 to the counter each time, and returns the new value to the client. Finally, list 2 shows the JavaScript code that initializes the callback function. It uses this. Page. ClientScript. GetCallbackEventReference to obtain a secure reference to the function that requires initialization callback.