Profiling ASP.net server control development-control life cycle

Introduction to the server control lifecycle

The lifecycle of a server control is the most important concept for creating a server control. As a developer, you must have a deep understanding of the server control lifecycle. Of course, this can not be done overnight. For beginners of learning control development techniques, you don't have to be very detailed and have a general idea of the different phases of the server control's lifecycle.

In mastering the lifecycle of the server control, readers should pay special attention to relevant content about server control state. While focusing on the various phases of the lifecycle, changes to the state of the server control note the following issues: When the control's lifecycle saves controls and restores their state, when to interact with pages and other controls, when to perform important processing logic, what information is available to the control at various stages, what data is persisted, The state in which the control is rendered and when the display markup text is printed, and so on. The following 11 stages of the server control lifecycle are listed below.

(1) initialization----in this phase, two main tasks are accomplished: First, initialize the settings required in the life cycle of the incoming Web request, and track view state. First, the page framework raises the Init event by default and calls the OnInit () method, which the control developer can override to provide initialization logic for the control. Thereafter, the page frame calls the TrackViewState method to track view state. It should be noted that in most cases, the TrackViewState method implementation provided by the control base class is sufficient. A developer may need to override the TrackViewState method only if the control has a complex property defined.

(2) Load view state----The primary task of this phase is to check whether the server control exists and whether it needs to revert its state to the state it was at the end of the request before processing. Therefore, the process occurs during page return rather than initialization of the request process. At this stage, the page framework automatically restores the ViewState dictionary. If the server control does not maintain its state, or if it has the ability to save all its state by default and use the ViewState dictionary, then the developer does not have to implement any logic. For situations where data types cannot be stored in the ViewState dictionary or require custom state management, developers can customize the recovery and management of the state by overriding the LoadViewState method.

(3) Processing postback data----to enable the control to check the form data that the client sends back, the LoadPostData () method of the System.Web.UI.IPostBackDataHandler interface must be implemented. Therefore, only controls that handle postback data are involved in this phase.

(4) Load----at this stage, the server control in the control tree has been created and initialized, the state has been restored, and the form control reflects the client's data. At this point, the developer can override the OnLoad () method to implement the common logic for each request.

(5) Send a postback change notification----at this stage, the server control raises the event as a signal that the control state changes as a result of the postback (so that this stage is used only for the postback process). In order to establish this signal, the developer must again use the System.Web.UI.IPostBackDataHandler interface and implement the other side of the method-raisepostbackchangedevent (). The judgment process is: LoadPostData () returns True if the control state changes because of a postback, otherwise it returns false. The page frame tracks all controls that return true and invokes RaisePostDataChangedEvent () on those controls.

(6) Handling postback events----This phase handles the client event that causes the postback. To facilitate processing of client events on a server-side event, developers can implement this logic by implementing the RaisePostBackEvent () method of the System.Web.UI.IPostBackEventHandler interface at this stage. In this way, the server control will successfully capture the client events of the postback for server-side processing.

(7) Pre-rendering----This phase completes any work required before the control is built. Typically, you do this by overriding the OnPreRender () method. Note that at this stage, you can save changes made to the state of the control at the present stage, and changes made during the rendering phase are lost.

(8) Save state----If the server control is not maintained, or if it has the ability to save all of its state by default and use the ViewState dictionary, then the developer does not have to implement any logic at that stage. Because the process of saving the state is automatic. If a server control requires a custom state save, or a control cannot store a particular data type in a ViewState dictionary, you need to override the SaveViewState () method to implement state saving.

(9) Rendering----represents the process of writing markup text to an HTTP output stream. The developer customizes the markup text on the output stream by overriding the render () method.

(10) Disposal----In this phase, the release of references to expensive resources, such as database links, is accomplished by overriding the Dispose () method.

(11) The unload----completes the same work as the "dispose" phase, but the developer typically performs a purge in the Dispose () method instead of handling the Unload event.

Summary

Server controls play a pivotal role in the ASP.net 2.0 framework and are the most critical and important elements of building Web applications. For a good developer, it is important to master the basics of server controls. This paper introduces the concept, type, lifecycle and other key contents of server control. I hope readers will be able to firmly grasp these content, in order to write wonderful server control to lay a good foundation.