Note Only controls that handle postback events participate in this phase. RaisePostBackEvent method
(If IPostBackEventHandler is implemented)
Pre-rendering Perform any updates before rendering the output. Changes made to the control state during the pre-rendering phase can be saved, while changes made during the rendering phase will be lost. See Handling inherited events. PreRender Event
(OnPreRender method)
Save Status After this stage, the ViewState property of the control is automatically maintained into the string object. This string object is sent to the client and sent back as a hidden variable. To improve efficiency, the control can override the SaveViewState method to modify the ViewState property. See Maintaining the status in the control. SaveViewState method
Render Generates output presented to the client. See Rendering Server Controls. Render Method
Disposal Perform all final cleanup operations before destroying the control. References to expensive resources, such as database links, must be released at this stage. See Methods in Server Controls.
Dispose method
Uninstall Perform all final cleanup operations before destroying the control. The control author usually performs a clearing in Dispose without processing this event. UnLoad event (On UnLoad method)
From this table, we can clearly see the method and trigger time of a Page call from loading to unloading. Next, we will conduct some in-depth analysis of it.
After looking at the table above, a careful friend may ask, since OnInit is the beginning of the page life cycle, and in the previous lecture, we talked about the control being created in the subclass, then in this case, we can actually use the fields that are known in the parent class in the InitializeComponent method, which means that the initialization of the subclass is even before this?
In the third title, we talked about the ProcessRequest of the page class being the real beginning of the page declaration cycle. This method is called by HttpApplication (the call method is relatively complicated, so I have the opportunity to explain it separately). A Page's processing of requests starts with this method and view the source code by decompiling the .Net class library. We found that a "FrameworkInitialize" virtual method is defined in the base class: (it is the base class of page and user controls). Then, this method is first called in the ProcessRequest of Page. In the source code of ASPX generated by the generator, we found a trace of this method. All controls are initialized in this method, and the page's control tree is generated at this time.
The next thing is simple. Let's analyze each item in the page life cycle step by step:
1. Initialization
Init event and OnInit method corresponding to Page.
If you want to override, the recommended way of MSDN is to overload the OnInti method instead of adding a proxy for the Init event. There is a difference between the two. The former can control the order in which the parent class OnInit method is called, while the latter can only be executed after the parent class OnInit (actually it is called in OnInit).
2. Loading view status
This is a relatively important method. We know that for each request, it is actually handled by a different page class instance. In order to ensure the status between the two requests, ViewState is used.
The LoadViewState method is to obtain the last state from the ViewState, and according to the structure of the page's control tree, iterates through the entire tree with recursion, and restore the corresponding state to each control.
3. Process the postback data
This method is used to check whether the status of the control data sent back by the client has changed. Prototype of the method:
public virtual bool LoadPostData(string postDataKey, NameValueCollection postCollection)
postDataKey is the keyword that identifies the control (that is, the Key in the postCollection). postCollection is a collection containing postback data. We can override this method and check whether the postback data has changed. If so, it returns a True. "If the control status changes due to postback, LoadPostData returns true; otherwise, it returns false. The page frame tracks all controls that return true and calls RaisePostDataChangedEvent on these controls." (Excerpt from MSDN)
This method is defined in the following and is also a method that all custom controls that need to handle events need to be processed. For the Page we are discussing today, you can ignore it.
4. Loading
Load the corresponding Load event and OnLoad method. I believe most friends will be familiar with this event. The Page_Load method in the generated page is the method of responding to the Load event. For each request, the Load event will be triggered and the Page_Load method will be executed. I believe this is also the first step that most people know.
The Page_Load method responds to the Load event, which is defined in the class (this class is the ancestor of Page and all server controls) and is triggered in the OnLoad method.
Many people may have encountered such a thing, writing a PageBase class and then verifying user information in Page_Load. As a result, it is found that regardless of whether the verification is successful, the Page_Load of the subclass page will always be executed first. At this time, some security risks may be left. The user may execute the Page_Load method in the subclass without verification.
The reason for this problem is very simple, because the Page_Load method is added to the Load event in OnInit, and the OnInit method of the subclass first adds the Load event and then calls it, which causes the subclass Page_Load to be added first, and then executes first.
It is also very simple to solve this problem, there are two ways:
1) Overload the OnLoad method in PageBase, then verify the user in OnLoad, and then call it, because the Load event is triggered in OnLoad, so we can guarantee that the user is validated before triggering the Load event.
2) Call it first in the OnInit method of the subclass, so as to ensure that the parent class executes Page_Load first
5. Send a postback change notification
This method corresponds to the process of postback data in step 3. If the process of postback data returns True, the page framework will call this method to trigger the event of data change, so the postback data change event of the custom control needs to be triggered in this method.
This method is not very useful for Page. Of course, you can also define the data change events yourself based on Page, which is of course OK.
6. Handle postback events
This method is where most server control events are triggered. When the request contains information triggered by the control event (the server control event is another topic, I will discuss it in the near future), the page control will call the RaisePostBackEvent method of the corresponding control to raise the server-side event.
Here comes another common question:
People often ask why the data after the modification and submission has not been changed.
In most cases, they do not understand the triggering process of the server event. We can see that the triggering server event is after the Load of Page, that is, the page will first execute Page_Load, and then execute the click event of the button (taking the button as an example here). Many friends bind data in Page_Load and then handle changes in the button event. There is a problem with this. Page_Load is always executed before the button event, which means that before the data has time to change, the data binding code in Page_Load is executed first, and the original data is assigned to the control. When executing the button event, the original data is actually obtained, so of course the update will have no effect.
Changing this problem is also very simple. A more reasonable approach is to write the data-bound code into a method. Let's assume it is BindData:
Copy the codeThe code is as follows:
private void BindData()
{
//Binding data
}
Then modify PageLoad:
private void Page_Load( object sender,EventArgs e )
{
if( !IsPostBack )
{
BindData(); //Bind data when the page is accessed for the first time
}
}
Finally in the button event:
private Button1_Click( object sender,EventArgs e )
{
//Update data
BindData();//Rebound data
}
7. Pre-presentation
The final request processing will be transformed into a response sent back to the server. The pre-representation stage is to perform the state changes made before the final rendering, because before rendering a control, we must generate Html according to its properties, such as the Style attribute. This is the most typical example. Before pre-representation, we can change the style of a control. When pre-representation is performed, we can save the Style to display the style information of the Html as the rendering stage.
8. Save status
This stage is for the loading state. We have mentioned many times that different instances are being processed between requests, so we need to save the status of this page and control. This stage is the stage of writing the state into ViewState.
9. Present
At this point, the page's processing of the request has basically come to an end. In the Render method, the entire page's control tree will be recursed, the Render method will be called in turn, and the corresponding Html code will be written into the final response stream.
10. Disposal
In fact, it is the Dispose method, which will release the occupied resources, such as database connections, at this stage.
11. Uninstall
Finally, the page will execute the OnUnLoad method to trigger the UnLoad event, and handle the final processing before the page object is destroyed. In fact, providing this event is only a design consideration. Usually, the resource release will be completed in the Dispose method, so this method has become useless.
We briefly introduced the life cycle of the page and gave a less in-depth explanation of the handling of server-side events. Today, we mainly want everyone to understand the cycle of page execution. I will write some articles to discuss the events and life cycle of server controls in the future.
These contents are some of my experiences on Page research when I was studying. The specific details were not discussed in detail. For more content, please refer to MSDN. However, I have cited some common mistakes made by beginners and the reasons for the mistakes. I hope it can inspire you.