Asp.net page Lifecycle

When a page request is sent to the Web server, no matter whether the event is triggered by PAGE submission or page redirection, the page runs a series of events when it is created to be released. An ASP. NET page contains 10 events from creation to release.

(1) object initialization init event: the identifier of page Initialization is the init event. Controls in the page (including the page itself) are initialized for the first time in their initial form. After successfully creating the control tree of the pageProgramThis event is triggered. When an init event occurs, all controls declared statically in the. aspx source file are instantiated and Their default values are obtained. It should be noted that there is no view status information available for use. Although the oninit method can be reloaded, the system does not guarantee the order in which these control instances are created.

(2) Load view: After initialization, the page framework immediately loads the view status (viewstate) of the page ). The view status is a set of name/value pairs. For example, you can save the ID and text attribute values of the Textbox Control. It is generally used to store information to the server during a round trip, that is, to participate in HTTP requests and responses.

The page view status is stored in the <input type = "hidden"> Field and recorded as the value of _ viewstae. The view status is automatically maintained by ASP. ne. By Rewriting the loadviewstate component, developers can control how to restore the view state and how to film its content to the internal state. The loadviewstate method obtains the last state from the viewstate and uses recursion to traverse the entire tree based on the control tree structure of the page to restore the corresponding state to each control.

(3) process the send-back data: The view State is restored, and the status of each control of the page tree is the same as that of the control when the browser last presented the page. Next, update the status of these controls to send them to the client.

In the sending and processing phase, each control has the opportunity to update its status so as to accurately reflect the status of corresponding HTML elements on the client. For example, the HTML element corresponding to a server Textbox Control is <input type = text>. In the data sending and returning stage, the Textbox Control retrieves the current value marked by <input> and uses it to refresh its internal status. Each control extracts the corresponding values from the data to be sent and updates some of its attributes. The Textbox Control updates the 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.

The page framework implements the ipostbackdatahandler interface on each data submission control, and then stimulates the loadpostdata event. Through page parsing, it is found that the ipostbackdatahandle interface control is implemented, in this way, the control status can be correctly returned. When identifying a control, ASP. NET updates the correct control by matching the unique identifier of the Control. This identifier has a name value pair in the name value set and. This is one of the reasons that each control requires a unique identifier in all specific pages. Other steps are completed by the framework, such as determining whether each identifier is unique in the environment and the basic attributes of the control.

The lostpostdata method is prototype as follows:
Public Virtual bool loadpostdata (string postdatakey, namevaluecollection postcollection)

Postdatakey is the key word used to identify the control. It can be understood as the control ID. postcollection is a set that contains the returned data and can be understood as the view status value. This method returns a bool value. If it is true, the status of the control is changed due to sending back; otherwise, false is returned. The page framework will track all controls that return true and call the raisepostdatachangeevent event on these controls.

The loadpostdata method is composed of system .. web. webcontrols. control defined, and each added server control is also from the system .. web. webcontrols. control, so data sending and receiving does not require intervention.

(4) Load page: When the sending and processing ends, all controls on the page are updated based on the changes entered on the client. In this case, the onload event is triggered on the page. I believe most of my friends will be familiar with this event, using Visual Studio. the page_load method in the page generated by net is the method for responding to the load event. For each request, the load event is triggered and the page_load method is executed. You can use this method to perform page initialization, such as preparing database connection strings. In event reference, to improve performance, the ispostback attribute of the page class is usually used to determine whether data is sent back.

(5) raisepostdatachanged: As described in (3), after all controls that implement the ipostbackdatahandler interface are correctly updated, each control has a Boolean ID that identifies whether the data of the control is changed or maintained after the last submission. ASP. NET then searches for the changed identifier of any display control data through the search page and fires raisepostdatachanged. The raisepostdatachanged event is triggered only when all controls are updated after the load event occurs. This ensures that the data of other controls is not manually changed in the raisepostdatachanged event before the control is updated. Although you can also define data change events based on the page, this event is usually of great use.

(6) raisepostbackevent: After a server event is triggered due to a data change caused by a returned update, the objects that are returned will be processed in the raisepostbackevent event. This type of backhaul object is usually a control that is triggered when a button is clicked or its status changes. For example, the button triggers the happy onclick event, the client modifies the text of a text box, sets autopostback to true, and triggers the textchanged event.

ManyCodeAll are executed in this event, because this is the ideal place to control the event-driven logic. To ensure the correctness of the data presented to the browser, the raisepostbackevent event is finally triggered after a series of return events. Based on consistency considerations, the changed control will be passed in until the function is updated after execution. In the actual ASP. NET development work, the task is to pre-process the code before this event occurs.

(7) pre-rendering prerender: After processing the re-sending event, the page is ready for rendering. This phase marks the prerender event. Each control can take advantage of this opportunity to perform any last update operation that needs to be completed before the view State is saved and the output result is displayed. The final request processing will change to the server's response. The pre-presentation phase is to execute the state changes made before the final presentation, because before a control is rendered, HTML must be generated based on its attributes, such as the style attribute. This is a typical example. Before pre-rendering, you can change the style of a control. When pre-rendering is executed, you can save the style as the HTML style information displayed in the rendering phase.

(8) saveviewstate: the next state is saveviewstate. in this state, all controls and pages can refresh the content of their own savestate set. The view State is subsequently serialized, hashed, base64 encoded, and associated with the VI-EMSTATE to hide the self-end.

(9) Rendering view render: Here, in fact, the page's processing of requests has basically come to an end. In the render event, the called objects are also rendered as HTML, then, HTML is collected and sent to the customer. After receiving the HTML Tag, the customer reorganized the tag and displayed it to the customer. When a render event is reloaded, the developer can create a fixed-value HTML for the browser. At this time, any HTML created on the page has not yet taken effect. The render method uses the htmltextwriter object as a parameter and generates HTML for the browser. This is mainly used for the development of custom controls.

(10) dispose of disposed: Execute all final cleanup operations before the control is destroyed. In this phase, reference to expensive resources must be released, such as memory exit and database connection.

(11) unload: The final survival mark of a page is the unload event, which occurs before the Page Object is removed. In this event, you can call the dispose method to release any key resources (such as files, graphical objects, and database connections) that are used as much as possible ).