ASP. NET page life cycle

This article describes in detail the entire lifecycle of an ASP page and explains the events handled by each cycle.

1, initialize--Receives the client's request, produces the Page object of the corresponding pages, and initializes the Page object and its controls through the Page_Init event

The Page_Init event is only executed once, on the current page, for initializing the initial value of the Page object, and for the control initial value. You can include some client-side detection code in this event.

2, load viewstate-load view state, ViewState contains a collection of properties and values for the page control, the client passes a hidden control _viewstate to the server, recording the client's view current state

3, callback data processing-the control assignment of the page is extracted from 2 viewstate

4, page load-Page_Load event for loading control and other data. The page executes once per refresh,

IsPostback is used to interpret whether the first time the first load false-true-second load

5,raisepostbackchanged Event-the flag bit bool that gives the control whether it is updated

6, callback event processing--to 5,page has been loaded completed, all the control label and data are displayed, start processing client events, for a specific time processing process. such as clicking on an event for logical processing.

7, page pre-return--you can make final changes to the value of the control

8. Save viewstate--The collection of control properties and values that the server has processed and save it to the server for the next request

9, page back--Returns the page generated by the above steps to the client

10, destroying objects-call the Dispose event, destroy the resulting page, save server resources

The corresponding event:

Init

LoadViewState,

LoadPostData,

Load,

Raisepostdatachanged,

RaisePostBackEvent,

PreRender,

SaveViewState,

Render,

Unload

When a request for a Web page is sent to the Web server, possibly through a user submission, or through a hyperlink, the page then runs a sequence of events from creation to completion. When we try to build an ASP. NET page, this execution cycle is not to be considered. However, if manipulated correctly, the execution cycle of a page will be an effective and powerful tool. Many developers who write ASP. NET pages and user controls find that knowing what's going on and when it happens will be important to help you get the job done.

A Initializing objects
The control of a page (and the page itself) should initially be properly initialized. By making a reputation for all objects in the C # file's constructor, the page will know how many objects to create and their types. Once all the objects are known in the constructor, they can be accessed by inheriting classes, methods, events, or properties. However, if some objects are some of the controls specified in the ASPX file, then these controls will have no properties to say. At the same time, accessing them through code produces some unexpected errors, because these control instances do not have a deterministic order of creation (if they were created together). Of course, developers can overload initialization events via OnInit

Two Import ViewState data
After the event is initialized, all controls can be referenced only by their ID (because there is no corresponding DOM available). In LoadViewState this event, all the controls will get their first property: the ViewState property. This property will eventually be returned to the server to determine whether the page has been accessed by the user or is still being accessed by the user. The ViewState property is saved as a string of name/value pairs, containing information such as the text of the control and the value. This property is stored in the Value property of a hidden <input> control that is passed when the page is requested. This is a much better way to maintain and judge the state of the page than Asp3.0. Also, developers can overload the LoadViewState event function to set the value of the corresponding control.

Three Processing postback data with LoadPostData
At this stage of page creation, the server processes the form data (called Postback data in ASP. NET) submitted by controls on the page. When a page submits a form, the framework performs a IPostBackDataHandler interface operation on each control that submits the data. The page then executes the LoadPostData event, parses the page, finds each control that performs the IPostBackDataHandler interface operation, and updates the control state with the appropriate postback data. ASP. NET is done by matching the name/value pairs in the Namevalue set with the unique ID of each control. Therefore, on an ASP. NET page, each control must have a unique ID, and there can be a case where several controls have a common ID. Even if some of the controls are customized by the user, the framework assigns them their own unique IDs. After the LoadPostData event, the following Raisepostdatachanged event will be executed.

Four. Import Object  
in the Load event, the object is instantiated. All objects are first placed on a DOM page (called the control tree in ASP.) and can be referenced by code or related locations. This makes it easy for an object to get property values in HTML such as width, height, value, visibility, and so on, from the client. In the Load event, there are, of course, actions such as setting control properties. This process is the most important and major in the entire life cycle, and you can overload the Load event

Five by calling OnLoad. Raisepostbackchanged event  
As mentioned above, this event occurs after all controls have performed IPostBackDataHandler interface operations and are updated with the correct postback data. In this process, each control is given a Boolean value to flag that the control has not been updated. ASP. NET then looks for any controls that have been updated on the entire page and executes the Raisepostdatachanged event action. However, this event is done only after all the controls have been updated and the Load event has been completed. This guarantees that a control will not be manually changed in the Raisepostdatachanged event until the postback data is updated.  

Six. Handles the client postback event  
When events caused by postback data on the server side are complete, the object that produces the postback data executes the RaisePostBackEvent event action. However, this can happen because a change in the state of a control causes it to return the form to the server or the user clicks the Submit button to return the form to the server. In this case, there should be a corresponding processing code to reflect the event-driven object-oriented (OOP) programming principles. In order to meet the accuracy requirements of the data presented to the browser, the RaisePostBackEvent event is the last occurrence in a series of postback events.  .
controls that are changed during the postback process should not be updated after the execution function function is called. In other words, any data that changes due to an expected event should be reflected on the final page. You can modify the RaisePostBackEvent function to meet your requirements
 
Seven. Pre-presented object   The last moment that the
can change the object and save the change is this step-the pre-presentation object. This allows you to make final modifications to the properties of the control, the control tree structure, and so on. There is also no need to consider any changes to ASP. NET, because it is now out of the database call and ViewState update. After this step, all modifications to the object will eventually be determined and cannot be saved to the ViewState of the page. Developers can use OnPreRender to reload this step.  

Eight Save ViewState
All modifications to the page control are completed and ViewState is saved. The state data for the image remains in the hidden <input> control, and the object state data presented to the HTML is also obtained from here. In the SaveViewState event, the value can be saved to the ViewState object, but changes to the controls on the page cannot be made. You can use SaveViewState to reload this step.

Nine Render to HTML
The render event occurs when HTML is used to create a page that is output to the browser. During the render event, the page invokes objects in it to render them to HTML. The page can then be accessed by the user's browser in the form of HTML. When the render event is overloaded, developers can write custom HTML code that invalidates the original generated HTML and organizes the page according to the new HTML. The Render method uses an HtmlTextWriter object as a parameter and it displays the HTML as a Web page in the browser. There are still some modifications you can make, but they are just some of the changes on the client side. You can overload the render event

Ten Destroying objects
All objects should be destroyed after the presentation to HTML is complete. In the Dispose event, you should destroy all the objects that were created when the page was built. At this point, all the processing is complete, so destroying any remaining objects will not cause errors, including the Page object. Developers can overload the Dispose event

ASP. NET page life cycle