asp.net ajax Client Lifecycle Analysis (theory)

First, the introduction

Microsoft's ASP.net ajax framework, as a relatively perfect AJAX framework, has many aspects that deserve in-depth study. In this article, we will combine a concrete example to try to explore the client lifecycle process of the ASP.net AJAX framework.

"Note" Reading this article is best to combine "ASP." NET Application Life cycle Overview "and" ASP. NET page life cycle Overview "two articles to learn together.

Second, asp.net AJAX client lifecycle principles

Because ASP.net ajax framework in the development of ideas to learn a lot from the development of ASP.net 2.0 technology, and will be gradually "included" into the ASP.net 2.0; therefore, a ASP.net Ajax page also has its own lifecycle, and with a asp.net There is a large comparability between the 2.0 Web page life cycle.

The client events in the ASP.net Ajax page can support us both for traditional loopback or asynchronous loopback (that is, "local page refresh") to customize their own user interface. Also, these events can help us manage and use custom scripts throughout their browser-side page life cycle.

These client events are concentrated in the ASP.net AJAX Framework client class library. When you load a page with asp.net Ajax server controls, the classes are automatically instantiated by the framework. With the help of some APIs provided by these classes of clients, we can easily implement the binding capabilities of client events on the page. Because this part of the ASP.net AJAX client library is completely independent of the browser, the code we write can certainly work in all of the current popular browser environments.

In numerous client events, one of the most critical events is the load event of the application instance during the initialization request (' get ' mode) and the asynchronous loopback.

"Note" When the scripts in the Load event handler program start running, all other scripts and components should already be loaded and fully available.

When using server control UpdatePanel for local page refreshes, the most important of all related client-side events is the related events in the Sys.WebForms.PageRequestManager class. These important client events help you to complete a few common tasks, such as undoing the loopback, setting a higher priority for a loopback, and enabling the UpdatePanel control to produce a certain animation effect during the refresh, and so on. A deep understanding of all these client events will help us create pages or develop components based on the ASP.net AJAX framework. For example, if you are a web developer, you can use your own custom scripts for the page during loading and unloading.

Third, client class parsing

As we mentioned briefly earlier, the Sys.Application class and the Sys.WebForms.PageRequestManager class are the two most important classes throughout the ASP.net AJAX Web page client lifecycle. Next, we'll do an analysis.

When the browser requests a page that contains a ScriptManager control, the application class is instantiated. The application class is extremely similar to a server-side page control (page controls inherit from the server-side control class), but they also provide additional functionality for raising service-side events. Similarly, the application class derives from the client's Sys.Component class, but it throws a series of client lifecycle events.

If a page contains a ScriptManager control and several UpdatePanel controls, the page can implement a partial update (if, of course, the browser supports and initiates the local update feature). In this case, an instance of a PageRequestManager class will be created and functioning on the browser side. In fact, the client events raised by this PageRequestManager instance are all about asynchronous loopback.

Iv. adding event handlers for client events

To add or remove the appropriate event handlers for events raised by instances of the application class and PageRequestManager class, we can use the add_EventName and Reomve_eventname methods to complete these tasks. The following example shows how to add an event handler function named Myload to the Init event for the Application object:

Sys.Application.add_init(MyInit);// 添加事件处理器
function MyInit(sender) {…………}
//…………
Sys.Appplication.remove_init(MyInit);//移除相应的事件处理器

This code only illustrates the basic syntax of the operation, and we'll take a specific example.

V. Handling of application load and unload events

Note that to handle the load and unload events of the Application object, it is not necessary for us to explicitly bind an event handler function to these events, but rather to create the corresponding function directly using the reserved keyword pageload and pageunload. The following example shows how to add an event handler function for the application load event.

function pageLoad(sender, args) {…………}

The author notes online resources also say, "just use reserved keywords pageload and pageunload to create the appropriate function", but to get to the bottom of it: where exactly is this detail implemented? Interested readers can further delve into a set of "APIs" that are downloaded with the framework; This is a function that seems to be somewhat "confusing" (presumably a simple "obfuscation" process).

Vi. other client-related events

In this article, we focus only on the events provided by the application and PageRequestManager classes (because events associated with these two classes play a crucial role in the two client page lifecycle). In fact, Microsoft's Ajax class library also includes a special class-sys.ui.domevent for DOM element event operations. Here are some typical global methods for adding, clearing, and removing the corresponding event handler functions. These methods include:

-sys.ui.domevent.addhandler, abbreviated as $addhandler;

-sys.ui.domevent.clearhandlers, abbreviated as $clearhandlers;

-sys.ui.domevent.removehandler, abbreviated as $removehandler.

However, the events provided by DOM elements are not included in this article (and are relatively simple).

Depth analysis of related events in application and PageRequestManager

For convenience, we illustrate the application and PageRequestManager class-related client events in tabular form (all of which we can support with Ajax ASP. NET technology in the page. The sequence of events raised will be analyzed in a later example.

Event	Explain
Init (Initialization event)	This event is raised before all scripts are loaded and any one object is created. If you are developing a client component, then this init event gives you the opportunity to add the component to the page during the page life cycle. Thereafter, the component can be invoked by other components and scripts within the page life cycle. If you are a web developer, in most cases, it is recommended that you use the Load event instead of the Init event for processing. The "note" Init event is created only once when the page starts to build. Subsequent partial page refreshes will not raise this event again.
Load (Load event)	This event is raised after all the scripts have been loaded and the objects in the program (created using $create) have all been initialized. This event is raised for all loopback (also including asynchronous loopback) to the server. If you are a web developer, you can create a function called Pageload, which automatically provides a processor function for the Load event. Note that this pageload processor is invoked after the event handler (added by the Add_load method) in all load events. In addition, the Load event requires only one Sys.applicationloadeventargs object as an argument. You can use this parameter to determine whether the page is refreshed after it has been partially updated, and to determine which components were created after the last load event was raised.
Unload (Uninstall Event)	This event is raised prior to releasing all objects and Window.unload events in the browser. If you are a web developer, you can create a function named Pageunload, and then the system automatically provides an event handler function for the Unload event. This event happens to be invoked before the browser unloads the page. Because this is the last chance, we should release all the resources that are consumed by the code during the event.
PropertyChanged (Property Change event)	This event is raised when the property of a component changes. The Application object inherits this event from the component class. Typically, this event is used only by the component developer, which is raised when the Sys.Component.raisePropertyChange method is invoked while setting the appropriate set accessor for a property. This event requires a use of the Sys.applicationloadeventargs object as an argument.
Disposing (Release event)	This event is raised when the application instance is disposed. The event is inherited from the component class by the Application object.
initializerequest (Initialization request event)	This event occurs before an asynchronous request begins. You can use this event to cancel a traditional loopback and allow an asynchronous loopback to receive priority execution rights. The event uses only one Sys.WebForms.InitializeRequestEventArgs object as an argument. Through this object we can manipulate the element that raises the loopback or even the request object. The event also exposes a cancel property. If you set the value of Cancel to True, a new loopback will be revoked.
BeginRequest (Start request event)	This event occurs before an asynchronous request begins but the loopback is implemented to the server. The event is raised before an asynchronous loopback that is loopback to the server is started. If a loopback process already exists, it will be hard to stop (through the abortPostBack method). You can use this event to set the header information for the request or to display an animation in the page to prompt that the request is in progress. The event requires a Sys.WebForms.BeginRequestEventArgs object as an argument. We can also use this object to manipulate the element that raises the loopback or even the request object.
pageloading (page is loading event)	This event is raised after receiving an asynchronous loopback response from the server side and before any content in the page is updated. In actual development, we can use this event to provide some sort of custom transition effect for content that needs to be updated. The event requires a Sys.WebForms.PageLoadingEventArgs object as an argument. With this object, we can learn from the results of the most recent asynchronous loopback that the panel elements (such as div,span, etc.) in the page will be deleted and updated.
pageLoaded (page load completion event)	This event is raised after all page contents have been refreshed, whether the result of a synchronous loopback or an asynchronous loopback. When synchronizing loopback, only panel elements can be created, but in asynchronous loopback, the panel elements are created and updated. We can use this event to manage some kind of custom transition effect for content that needs to be updated. The event requires a Sys.WebForms.PageLoadedEventArgs object as an argument. This object provides useful information about which panel elements were updated and created during the most recent loopback.
EndRequest (end request event)	This event is raised when an asynchronous echo is completed and the page is updated, or when an error occurs during the request. If an error occurs, the page will not be updated. Therefore, we can use this event to provide a custom error message to the visitor or to record the information in the error log. The event requires a Sys.WebForms.EndRequestEventArgs object as the EventArgs parameter. This object provides some useful information about whether the raised error and error were handled, and we can manipulate the response object through this object.

Viii. Summary

In this article, we will give a detailed enumeration of the important events in the ASP.net AJAX client lifecycle and provide typical applications. In the next installment, we analyze a real simple case and attempt to parse the sequence of the major associated events in the ASP.net AJAX client lifecycle.