Asp.net page Lifecycle

Extracted from: [ASP. NET development Q & A 200 Q & A] book ..
① Page initialization ---------- after receiving a request from the client, the Page Object of the corresponding page is generated, and the page object and its control are initialized through the page_init event.
② Load view status ------- viewstate is a set of attributes and values of the Page Server Control. The client uploads the control through a hidden control _ viewstate to the server (the server also has such a variable, this step is to use the viewstate on the server side. Compared with the _ viewstate passed by the client, it is an old version.) ________ this is not necessarily true and is purely a personal understanding.
=. Continue

③ Return data processing ------- locate _ viewstate from the customer request in step 1, extract the data, and assign values to the page control.
④ Page loading ------------ execute the load () event. It feels like page_load (), objects are all instantiated, (controls are assigned values. Here the instantiation refers *. class in CS, as if)
⑤ Raisepostbackchanged event --------- the control is assigned a bool value to identify whether it has been updated.
6. Handle the return event ------- it is the events triggered by the client and starts to execute. For example, if you press a button or something, the specific process to be executed.
7. Page pre-return stage-the last opportunity to modify the property value of the control and the control tree structure.
Secrets save viewstate ------- store the properties and values of the server control in viewstate (server side) for the next page request. therefore, compared to the next request for this page, the viewstate is an old version.
Response page return stage ------- send the generated page to the client.
Destroy destroy object ------------ call the dispose event to destroy the webpage and release all resources it occupies.

The processing of a client request on the server is completed .!!!!!
1. initialize the object
Ii. Import viewstate data
3. Use loadpostdata to process PostBack data
Iv. Import objects
5. raisepostbackchanged event
6. Process client PostBack events
VII. Pre-Submission objects
8. Save viewstate
9. Submit to HTML
10. Destroy objects
The above are ten events in the lifecycle of the Asp.net page. Every time we request an Asp.net page, we go through the same process from initializing objects to destroying objects.

 

Init,

Loadviewstate,

Loadpostdata,

Load,

Raisepostdatachanged,

Raisepostbackevent,

Prerender,

Saveviewstate,

Render,

Unload

Asp.net page events from initialization to uninstallation
The customer sends a POST request-> Create a page derived class and call the constructor-> call the ihttphandler of the page class. processrequest method-> activate the init event of the page class-> call the createchildcontrols virtual method of the page class-> restore the server-side control status from the post variable and viewstate-> activate the load event of the page class -> activate the control event on the server-> activate the prerender event of the page class-> call the render virtual method of the page class-> call the renderchildren virtual method of the page class-> send an HTTP Response to the client -> activate the unload event of the page class-> discard the instance of the page derived class.

Introduction
Asp.net is an integral part of Microsoft's. NET strategy. Compared with ASP, it has developed a lot and introduced many new mechanisms. This article will give a preliminary introduction to the lifecycle of the Asp.net page, in order to help you better and more flexibly manipulate Asp.net.
When a request for obtaining a webpage (either submitted by the user or through a hyperlink) is sent to the Web server, this page then runs a series of events from creation to processing. When we try to create an Asp.net page, this execution cycle does not have to be considered, so it will only suffer. However, if correctly manipulated, the execution cycle of a page will be an effective and powerful tool. When writing pages and user controls of Asp.net, many developers find that it is very helpful to complete the entire task if they know what happened and when it happened. Next I will introduce you to the ten events in the next Asp.net page from creation to processing. It also shows you how to add your own Code To achieve the expected effect.
1. initialize the object
A page control (and the page itself) should be correctly initialized at first. By calling all objects in the constructor of your C # file (1), the page will know how many objects to be created and their types. Once you name all objects in your constructor, you can access them by inheriting classes, methods, events, or attributes. However, if some of your objects are some controls specified in the aspx file, these controls have no attributes. At the same time, accessing them through code will produce some unexpected errors, because these control instances do not have a definite order of creation (if they are created together ). In addition, you can use oninit to reload initialization events, as shown in figure 1 ):


Figure 1

Ii. Import viewstate data
After the initialization event, all controls can only be accessed by referencing their IDs (because there is no corresponding Dom available ). In the loadviewstate event, all controls get their first property: viewstate. This attribute will 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 attribute is saved as a string of the "name/value" pair. It contains the control text, value, and other information. This property is stored in the value property of a hidden <input> Control and passed on the request page. This method is much more advanced than how asp3.0 maintains and judges the page status. In addition, you can reload the loadviewstate event function to set the value of the corresponding control. (Figure 2) is an example:


Figure 2

3. Use loadpostdata to process PostBack data
At this stage of page creation, the server processes the form data submitted by the control on the page (called PostBack data in Asp.net. When a page submits a form, the Framework executes an ipostbackdatahandler interface operation on each control that submits data. Then, the page executes the loadpostdata event, parses the page, finds each control that executes the ipostbackdatahandler interface operation, and updates the status of these controls with the appropriate PostBack data. Asp.net performs this operation by matching the unique ID of each control with the "name/value" pair in the namevalue set. Therefore, on the Asp.net page, each control must have a unique ID, and several controls cannot have a common ID. Even some custom controls, the framework will grant them unique IDs. After loadpostdata event, execute the following raisepostdatachanged event.
Iv. Import objects
In the load event, all objects are instantiated. For the first time, all objects are placed in the DOM page (called the control tree in Asp.net) and can be referenced through code or related locations. In this way, the object can easily obtain attribute values in HTML from the client, such as width, height, value, and visibility. In the load event, operations such as setting control properties also occur. This process is the most important and important throughout the lifecycle. You can call onload to overload the load event, as shown in figure 3 ):


Figure 3

5. raisepostbackchanged event
As mentioned above, this event occurs after all controls perform the ipostbackdatahandler interface operation and are updated by the correct PostBack data. In this process, each control is assigned a Boolean value to indicate whether the control has been updated. Then, Asp.net searches for any updated controls on the entire page and executes the raisepostdatachanged event operation. However, this event is performed only after all controls are updated and the load event is complete. This ensures that other controls will not be manually changed in the raisepostdatachanged event before being updated by the PostBack data.
6. Process client PostBack events
When all events caused by PostBack data on the server are completed, the object that generates the PostBack data executes the raisepostbackevent event operation. In this case, the status of a control changes, so that it returns 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 corresponding processing code to reflect the event-driven object-oriented programming principle. To meet the data accuracy requirements presented to the browser, the raisepostbackevent event is the final occurrence in a series of PostBack events.
Controls changed during the PostBack process should not be updated after function execution is called. That is to say, any data changed due to an expected event should be reflected on the final page. You can modify the raisepostbackevent function to meet your requirements, as shown in figure 4 ):


Figure 4

VII. Pre-Submission objects
This step is the last time the object can be changed and saved-the pre-submitted object. In this way, you can make the final modification to the properties and tree structure of the control. At the same time, you do not need to consider making any changes to Asp.net, because it is out of the database call and viewstate update. After this step, all modifications to the object will be final and cannot be saved to the viewstate of the page. You can use onprerender to reload this step.
8. Save viewstate
After all the page controls are modified, the viewstate is saved. The status data of the object is still stored in the hidden <input> control. The object status data presented to HTML is also obtained from here. In the saveviewstate event, the value can be saved to the viewstate object. However, the modification of the control on the page cannot be performed. You can use saveviewstate to reload this step, as shown in Figure 5 ):


Figure 5

9. Submit to HTML
The render event occurs when a page is created using HTML to be output to the browser. During the render event process, the objects in the page are called to submit them to HTML. Then, the page can be accessed by the user's browser in the form of HTML. When a render event is overloaded, developers can write custom HTML code to make the originally generated HTML invalid and organize pages according to the new HTML. The render method uses an htmltextwriter object as a parameter and uses it to display HTML in the browser as a webpage. Some modifications can be made at this time, but they are only some changes on the client. You can reload the render event, as shown in figure 6 ):


Figure 6

10. Destroy objects
After being submitted to HTML, all objects should be destroyed. In the dispose event, you should destroy all the objects created when this page is created. At this time, all the processing has been completed, so the destruction of any remaining objects will not produce errors, including page objects. You can reload the dispose event, as shown in figure 6.
Summary
The above are ten events in the lifecycle of the Asp.net page. Every time we request an Asp.net page, we go through the same process: from initializing an object to destroying an object. By understanding the internal operation mechanism of the Asp.net page, I believe that you will be more comfortable writing and debugging code.