Key events and execution steps of ASP. NET page Lifecycle

Introduction to ASP. NET page Lifecycle

Once the HTTP page handler class is fully determined, ASP. NET calls the ProcessRequest method of the handler to process the request when it is running. Generally, you do not need to change the implementation method of this method because it is provided by the Page class.

This implementation method calls the FrameworkInitialize method at the beginning to establish the control tree of the page. This method is a protected Virtual Member of the TemplateControl class Page class itself derived from this class. Any handler dynamically generated for. aspx resources overwrites FrameworkInitialize. In this method, the complete control tree of the page is built.

Next, ProcessRequest makes the page go through several stages: initialization, loading view status information and sending back data, loading the user code of the page, and executing the sending back server event. Then, the page enters the rendering mode: Collect the updated view status, generate HTML code, and send it to the output console. Finally, uninstall the page and consider that the request has been processed successfully.

In each stage, the page will inspire some Web controls and user-defined code to intercept and process events. Some of these events are dedicated to embedded controls, so they cannot be processed at the. aspx code level.

If the Page wants to process an event, it should explicitly register the corresponding handler. However, to be backward compatible with earlier Visual Basic programming styles, ASP. NET also supports an implicit event suspension form. By default, the page will try to match the specific method name with the event. If a matching method is found, the method is considered as the event handler. ASP. NET provides specific identification of six method names. They are Page_Init, Page_Load, Page_DataBind, Page_PreRender, and Page_Unload. These methods are treated as the corresponding event handler provided by the Page class. During HTTP runtime, these methods are automatically bound to page events, so that developers do not have to write the required bonding code. For example, the method named Page_Load is bound to the Load event of the page, just as if the following code has been written.

 
 

  
  
this.Load += new EventHandler(this.Page_Load);  
 
 

This function automatically identifies special names is controlled by the AutoEventWireup attribute of the @ Page command. If this attribute is set to false, any application that wants to process an event needs to explicitly connect to the page event. If the page does not use the automatic event Association function, you do not need to perform any additional operations to match the names and events, thus improving the performance. Note that the AutoEventWireup attribute is disabled when all Microsoft Visual Studio. NET projects are created. However, this attribute is set to true by default, meaning that methods such as Page_Load are recognized and bound to related events.

The page execution process includes a series of stages listed in the following table, and features application-level events and/or protected and Rewritable methods.

Table 1. Key events in ASP. NET page Lifecycle

Phase	Page events	Rewritable Method
Page Initialization	Init
Load view status		LoadViewState
Process the returned data		ImplementationIPostBackDataHandlerTheLoadPostDataMethod
Load page	Load
Send a change notification		ImplementationIPostBackDataHandlerTheRaisePostDataChangedEventMethod
Handle sending back events	Any sending event defined by the Control	ImplementedIPostBackEventHandlerTheRaisePostBackEventMethod
Page pre-rendering stage	PreRender
Save view status		SaveViewState
Rendering page		Render
Uninstall page	Unload

At the Page level, some stages listed above are invisible and only affect server control writers and developers who coincidentally want to create classes derived from pages. The activity signals sent from the page to the outside world only include Init, Load, PreRender, Unload, and all the sending events defined by the embedded control.

ASP. NET page lifecycle: stages of execution

The first phase in the page lifecycle is initialization. The identifier of this phase is the Init event. After the control tree of the page is successfully created, the event is triggered to the application. In other words, when the Init event occurs, all controls declared statically in the. aspx source file have been instantiated and Their default values are taken. The control can suspend the Init event to initialize any settings required in the lifecycle of incoming Web requests. For example, the control can load an external template file or set the event handler. Note that no view status information is available.

After initialization, the page framework immediately loads the view status of the page. The view status is a set of name/value pairs. Controls and pages can store any information that must always be valid for all Web requests. View status indicates the call context of the page. Generally, it contains the status of each control when the page was last processed on the server. When a page is requested for the first time in a session, the view status is empty. By default, the view status is stored in a hidden field, which is automatically added to the page. The field name is _ VIEWSTATE. By overwriting the LoadViewState method, a protected and Rewritable method of the Control class) component developers can Control how to restore the view State and map its content to the internal state.

Some methods, such as LoadPageStateFromPersistenceMedium and its relative SavePageStateToPersistenceMedium, can be used to load the view status and save it to other storage media such as files on sessions, databases, or servers. Unlike LoadViewState, the above method is only available in the classes derived from Page.

Once the view status is restored, the status of each control in the page tree is the same as that when the browser last presents the page. The next step is to update the status of these controls to add changes to the client. In the sending and processing phase, each control has the opportunity to update its status to accurately reflect the status of corresponding HTML elements on the client. For example, the HTML element of a server TextBox Control is <input type = text>. In the send-back data phase, the TextBox Control will retrieve the current value marked by <input> and refresh its internal status with it. Each control extracts the corresponding values from the sent data and updates some of its attributes. The TextBox Control updates its Text property, while the CheckBox control refreshes its Checked property. The matching relationship between the Server Control and HTML elements is determined by the IDs of the two.

At the end of the sending and processing stage, all controls on the page update the original status based on the changes entered on the client. In this case, the Load event is triggered on the page.

If a sensitive property is modified when two different requests are processed, some controls on the page may need to complete some tasks. For example, if the text of a text box control is modified on the client, the control fires the TextChanged event. If one or more properties of the control are modified using the value from the client, each control can decide to trigger an appropriate event. For controls, if these changes are crucial, these controls implement the IPostBackDataHandler interface and call the LoadPostData method of the interface immediately after the Load event. By writing the LoadPostData method code, a control can check whether any key changes have occurred since the last request and trigger its own change events.

The key event in the page lifecycle is that it is called to execute the server-side code associated with an event triggered on the client. When you click a button, the page returns data. This button is included in the set of sent values to start the entire operation. If it is known that the control implements the IPostBackEventHandler interface button and the link button), the page Framework calls the RaisePostBackEvent method. The operation performed by this method depends on the type of the corresponding control. For buttons and link buttons, this method finds the Click event handler and runs related delegation.

After processing the send-back event, the page is ready for rendering. This phase marks the PreRender event. Each control can take advantage of this opportunity to execute any last update operations that need to be completed one minute before the view State is saved and the output result is displayed. The next state is SaveViewState. in this state, all controls and the page itself can refresh the content of their ViewState set. The obtained view status can be serialized, hashed, Base64 encoded, and associated with the _ VIEWSTATE hidden field.

By Rewriting the Render method, you can change the rendering mechanism of each control. This method gets an HTML writer object and uses this object to aggregate all the HTML text generated for this control. The default implementation method of the Page class Render method includes recursive calls to all member controls. For each control, the page calls the Render method and places the HTML output to the cache.

The final survival mark of a page is the Unload event, which occurs before the Page Object is removed. In this event, you should release any key resources that may be occupied, such as files, graphical objects, and database connections ).

Finally, after this event, the browser receives the HTTP response packet and displays the page.

1. ASP. NET Page object model: Page class Introduction
2. Describe ASP. NET page forms
3. Introduction to ASP. NET pages
4. Detailed description of ASP. NET page Lifecycle
5. Notes for adding an ASP. NET page