Page Lifecycle Learning Summary (Translation and Notes)
Original link: Page Events: Order and PostBack Author: Paul Wilson translation: wood Wildfox
Initialization
When the page is requested, the first constructor is always constructed. You can initialize a lot of custom properties or objects here. However, there are some restrictions because Page has not been fully initialized. In particular, you must use httpContext.current to access querystring, form, cookies collection, and cache objects. And the Session object is unable to access in the constructor.
The following is then executed, and this method adds all subcipes that make up the PAGE to the control set tree. In many advanced page template solutions, this method is usually overridden to add a control of the page to a special page template. The method recursated by the method, all of these sub-controls are initialized at this time, from the beginning of the most inside.
Then the determinePostBackMode method. This method allows you to affect the value of ISPostBack, as well as related events. This may be useful to you if you want to load ViewState from the database to Redirect. Because ViewState is only recovered when ISPOSTBACK is TRUE. You can force the postback by returning null, or returns Request.form to force the postback. This method is not recommended, unless it is in special cases, because he also affects other events.
Then is the OnNit method. Usually this is the first method we use. At this time, all controls have been initialized, that is, all original values are set. ViewState and all other POST values have not been applied to the control. That is to say, all changes made by code or user operation have not been recovered yet. This is usually the best time to create or recreate dynamic controls.
Restore and load (Restore and Load)
The next loadpagestateFromPersistencemedium method is performed only when Postback is in Postback. When you want to change the way to save ViewState (using session or other custom storage methods), override this method, as well as the later SavePageStateTopersistenceMedium method. Note: This method does not really load ViewState to Page and its sub-controls.
After ViewState is retrieved, then the loadViewState method returns them to Page and recursively restores it to each sub-control (only Postback's). At this time, each control has been restored to the status of its last execution, but The value of the user's POST has not been applied. Because this belongs to viewState. This method is the best time to restore all dynamic controls created in the event.
The next is the ProcessPostData method. It is only performed when postback is in Postback. And this method cannot be covered because it is a private method implemented in the page base class. This method finally restores the value of the user POST to the page by matching the name of the control. At this time, Page has been completely recovered. Dynamic controls must be created before this method. This method also changes to the value of the Changed event record control.
Then is the online method. This method is used in most code, because this is in the life cycle of Page, where all values are restored. We can avoid unnecessary reset by checking the ISPostBack properties. At the same time, you can also check the isvalID property to verify. You can also create dynamic controls here. All of these controls are executed and captured, including viewState. But the returned value is not. Raised Events
The next method, the ProcessPostData method is actually the second entrance to the previous method. It only processes the return, and because it is a private method, it cannot be covered. This method is somewhat surprises, but it is necessary. Since the dynamic control reconstructed in the OnLoad method requires the value they return. All dynamic controls created after this method will only resume ViewState, and cannot recover the retraired values and cannot trigger any changes to events.
The next method, RaiseChangeDevents, is equally only used for fur. It is a private method implemented by a base class. At this time, the CHANGED event is triggered. This is based on the difference in the value of the rapid repulsion based on the previous ProcessPostData method. When a plurality of CHANGED events are triggered, their order is not guaranteed.
Below is a RaisePostBackeVent method. For flexion, and is a private method implemented by the base class. This is a method that truly submits FORM unless it is postback. For example, buttons, or other controls submitted by JavaScript are triggered. If you use Validators, if you don't call the validate method manually, it has been called. Sometimes IE's bug will make the form being submitted without triggering an event.
Then the OnPrender method. This is usually changed to the last chance of Page and its sub-controls before being drawn to the browser. You can also create dynamic controls here. But you can only capture ViewState without receiving Posted Values, and there is no event. Because of the BUG mentioned above, here can be used to capture a Post back without triggering events.
Save and Draw (Save and Render)
The next is the SaveViewState method. No matter whether post back. Remature application is applied to each sub-control. ViewState generally holds different attributes in all and the ASPX page, whether it is coded or user changes. Note that since the value of the control is saved by their position in the control tree, if the dynamic control to the wrong position is added, ViewState may crash.
Below is the SavePageStateTopistenceMedium method. It really saves the ViewState. This method can be overwritten. If you rewrite, pay attention to the BUG of ASP.NET, you need to manually set __viewstate, even if it is null.
Then the render method. It recursively calls to each sub-control, real draws its respective HTML and sends it to the browser. In some page template schemes, common header and footer are often added here. Not use to use server controls. Note that the changes that can be made here must be pure html. Because the controls have been drawn at this time.
Finally the ONUNLOAD method. It calls the Dispose method. This method can be used to clean up the non-hosting resources used in the page. Especially similar to the closed file or database connection, etc. This method only occurs when the page has been sent to the client browser. So it can only work on the objects of the server. So he cannot be displayed in the Page's Trace.
The above is the life cycle of Page. Each time there is a new request, the above process is repeated once.
Listing 1: Page's Event Summary
MethodPostBackControlsConstructorAlwaysAllAddParsedSubObjectAlwaysAllDeterminePostBackModeAlwaysPageOnInitAlwaysAllLoadPageStateFromPersistenceMediumPostBackPageLoadViewStatePostBackAllProcessPostData1PostBackPageOnLoadAlwaysAll
ProcessPostData2PostBackPageraiseChangeDeventspostbackPageraisePostBackeVentPostBackPageonPrenendralwaySall
SaveViewStateAlwaysallsavepagestateTopersistenceeMediumalwaySpagerendralwaySallonunloyadalwaySall
