Page loading order, with the Master Loading Order

Initialization)

When a page is requested, the first one is always executedConstructor)You can initialize many custom attributes or objects here. However, there are some restrictions, because the page has not been fully initialized. Specifically, you must use HttpContext. Current to access QueryString, Form, Cookies, and Cache objects. The Session object cannot be accessed in the constructor.

Next we will executeAddParsedSubObject MethodThis method adds all the child controls that make up the page to the control set tree. In many advanced Page Template solutions, this method is usually overwritten to add page controls to a special page template. This method recursively calls quilt controls. All these child controls are initialized at this time, starting from the very beginning.

NextDeterminePostBackMode Method. This method allows you to influence the IsPostBack value and related events. This may be useful if you want to load ViewState from the database for redirect. Because ViewState is restored only when IsPostBack is true.
You can forcibly disable postback by returning null, or return Request. form to force postback. this method is not recommended unless it is in special circumstances because it also affects other events.

ThenOnInit Method. This is usually the first method we use. At this time, all controls have been initialized, that is, all original values have been set. ViewState and all other post values have not been applied to the control. That is to say, all the changes made through code or user operations have not been restored. This is usually the best time to create or recreate a dynamic control.

Restore and Load)

NextLoadPageStateFromPersistenceMedium MethodIs executed only in PostBack. When you want to change the method for saving ViewState (using Session or other custom storage methods), overwrite this method and the SavePageStateToPersistenceMedium method. Note: This method does not actually load ViewState to the page and its child controls.

After ViewState is retrievedLoadViewState MethodRestore them to the page and recursively restore them to each sub-control (only those of PostBack ). at this time, each control has been restored to the status when it was last executed, but the user's post value has not been applied. This is ViewState. This method is the best time to restore all the dynamic controls created in the event.

Next isProcessPostData Method. It is executed only at the time of PostBack. This method cannot be overwritten because it is a private method implemented in the base page class. This method will eventually restore the user's post value to the page by matching the control name. The page is completely restored. The dynamic control must be created before this method. This method also records changes in the control value for later changed events.

ThenOnLoad Method. This method is used in most code, because this is the first place in the lifecycle of the page where all values are restored. We can check the IsPostBack attribute to avoid unnecessary resetting status. You can also check the IsValid attribute for verification. You can also create dynamic controls here. All the methods of these controls will be executed and captured, including ViewState. However, the resend value is not allowed.

Raised Events

Next method,ProcessPostData MethodIn fact, it is the second entry (second pass) of the previous method ). It only processes sending back, and cannot be overwritten because it is a private method. This method seems strange, but it is necessary. Because the dynamic controls rebuilt in the OnLoad method need their return value. All the dynamic controls created after this method can only restore ViewState, but cannot restore the value of sending back, and cannot trigger any change events.

Next method,RaiseChangedEventsAnd only for sending back. It is a private method implemented by a base class. The changed event is actually triggered. This is based on the difference in the returned value marked in the ProcessPostData method. When multiple changed events are triggered, their order is not guaranteed.

Below isRaisePostBackEvent Method. Only used for sending back, and is a private method implemented by the Base class. This is the method for actually submitting the form, unless it is postback. For example, buttons or other controls submitted through javascript are triggered. If Validators is used, if the Validate method is not manually called, it is also called. Sometimes, the ie bug causes the form to be submitted without triggering an event.

NextOnPreRender Method. This is usually the last chance to change the page and its sub-controls before being drawn to the browser. You can also create dynamic controls here. However, ViewState can only be captured, but posted values cannot be accepted, and no event exists. Because of the ie bug mentioned above, it can be used to capture the post back that does not trigger the event.

Save and Render)

Next isSaveViewState Method. Whether or not post back. recursively applies to each sub-control. ViewState stores all properties different from those on the aspx page, whether it is changed by code or users. Note: because the control values are saved by their locations in the control tree, if dynamic controls are added to the wrong position after this, ViewState may crash.

Below isSavePageStateToPersistenceMedium Method. It actually saves the ViewState of the page. This method can be overwritten. If it is overwritten, note that due to the bug in asp.net, You need to manually set the _ VIEWSTATE, even if it is a null value.

NextRender Method. It recursively calls each sub-control, truly draws its own html, and sends it to the browser. In some Page Template schemes, General headers and footer are often added here instead of server controls. Note that the changes that can be made here must be pure html, because the controls have been drawn.

FinallyOnUnload Method. It calls the Dispose method. This method can be used to clear the unmanaged resources used in the page. In particular, it is similar to closing open files or database connections. This method occurs only when the page has been sent to the client browser. Therefore, it can only work on objects on the server. Therefore, it cannot be displayed in the trace of the page.

The above is the lifecycle of the page. Each time there is a new request, the above process is repeated once.

Listing 1: Page event Summary

Method	PostBack	Controls
Constructor	Always	All
AddParsedSubObject	Always	All
DeterminePostBackMode	Always	Page
OnInit	Always	All
LoadPageStateFromPersistenceMedium	PostBack	Page
LoadViewState	PostBack	All
ProcessPostData1	PostBack	Page
OnLoad	Always	All
ProcessPostData2	PostBack	Page
RaiseChangedEvents	PostBack	Page
RaisePostBackEvent	PostBack	Page
OnPreRender	Always	All
SaveViewState	Always	All
SavePageStateToPersistenceMedium	Always	Page
Render	Always	All
OnUnload	Always	All

 

 

 

 

Application: BeginRequest
Application: PreAuthenticateRequest
Application: AuthenticateRequest
Application: PostAuthenticateRequest
Application: PreAuthorizeRequest
Application: AuthorizeRequest
Application: PostAuthorizeRequest
Application: PreResolveRequestCache
Application: ResolveRequestCache
Application: PostResolveRequestCache
Application: PreMapRequestHandler
Page: Construct
Application: PostMapRequestHandler
Application: PreAcquireRequestState
Application: AcquireRequestState
Application: PostAcquireRequestState
Application: PreRequestHandlerExecute
Page: AddParsedSubObject
Page: CreateControlCollection
Page: AddedControl
Page: AddParsedSubObject
Page: AddedControl
Page: ResolveAdapter
Page: DeterminePostBackMode
Page: PreInit
Control: ResolveAdapter
Control: Init
Control: TrackViewState
Page: Init
Page: TrackViewState
Page: InitComplete
Page: LoadPageStateFromPersistenceMedium
Control: LoadViewState
Page: EnsureChildControls
Page: CreateChildControls
Page: PreLoad
Page: Load
Control: DataBind
Control: Load
Page: EnsureChildControls
Page: LoadComplete
Page: EnsureChildControls
Page: PreRender
Control: EnsureChildControls
Control: PreRender
Page: PreRenderComplete
Page: SaveViewState
Control: SaveViewState
Page: SaveViewState
Control: SaveViewState
Page: SavePageStateToPersistenceMedium
Page: SaveStateComplete
Page: CreateHtmlTextWriter
Page: RenderControl
Page: Render
Page: RenderChildren
Control: RenderControl
Page: VerifyRenderingInServerForm
Page: CreateHtmlTextWriter
Control: Unload
Control: Dispose
Page: Unload
Page: Dispose
Application: PostRequestHandlerExecute
Application: PreReleaseRequestState
Application: ReleaseRequestState
Application: PostReleaseRequestState
Application: PreUpdateRequestCache
Application: UpdateRequestCache
Application: PostUpdateRequestCache
Application: EndRequest
Application: PreSendRequestHeaders
Application: PreSendRequestContent

 

 

MasterPage Loading Sequence

1. page_init2 of the user control in the Master page. page_init3 of the user control in the Aspx page. page_init4 of the Master page. page_init5 of Aspx. page_load6 of Aspx. page_load7 of Master page. page_load8 of the user control in the Master page. page_load of the user control in the Aspx page