Original address:
http://aspalliance.com/articleviewer.aspx?aid=134&pid=
Instantiate
The first method performed by a page is always constructed. Although this time, due to the page yet fully initialized, some restrictions will be generated, but you can instantiate custom properties or objects in many pages. In particular, you can access Request QueryString, Form, cookies collection, and cache objects via HttpContext.current objects. However, the session collection cannot be accessed in the constructor.
The next executed event is the AddParsSubObject method, which is actually added to the control tree of all components page. In order to put the page content to a specific control in the page template, this method is typically overloaded in some advanced page template solutions. This method will be recursively called each child control in the page control, and each such control will begin to be initialized from the outermost layer.
The method in the page class that is executed is DeterminePostBackMode. This method allows you to respond to the value of IsPostback and all related events, if you need to import ViewState from the database to redirect, it will be useful because ViewState is only recovered when ISPOSTBACK is TRUE. Since it will affect other events, in addition to some special occasions, it is not necessary to return a null and return to Request.form for forced Postback.
The following event is the page OnNit method, which is usually the first method used. At this time, all the controls defined in the page will be initialized, which means that all the original values specified in the ASPX page will be applied. However, ViewState and any submitted values have not been applied to the control, so any code or the value of the user changes has not been recovered. This is usually a good place to create and recreate dynamic controls.
Restore and loading
The next method is only loadpagestateFromPersistencemedium that is performed at Postback. This method will overload when you change the page viewState saved by Session or custom storage method in later SavePageStateToPersistenceMedium methods. The default execution assumes that viewState is a hidden form field of 64 cardiostext, but this can be changed in these two methods in this related article. Note that this method does not actually resume ViewState to page or page control.
After reoming ViewState, the next method is also the loadViewState that is executed after Postback, which restoress ViewState to the page and recursively to each control and their child control. After this execution, each control will be restored to the last state, but the value submitted by the user is not an application because this is not part of ViewState. The best use of this method is to recover any dynamic controls you created in the event of the value you must be saved in the viewState, and this control can now be used.
The next method is ProcessPostData executed in Postback, since it is a private method executed by the page base class, it is not overloaded. This method finally uses the value of the control to restore the value submitted in the user form, which means that the page will eventually recover. The only thing to capture is that the dynamic control must be created before this page method. This is also a method of logging a change in the event after changing the event.
The next execution is the onload method of the page, since it is the first place to recover all the values in the page lifecycle, most of this method is usually adopted. Most of the code To avoid unnecessary reset, check whether it is ispostback. You can call the Validate method in this method to check if the page is valid. You can also create dynamic controls in this method, and all control methods include ViewState will be executed in order to catch the parent control, but the value submitted cannot be recovered. Incident
The next method is the second execution of previous ProcessPostData, which is still only executed after Postback and cannot be overloaded due to private methods. When you first pay attention to it twice in the page trace, it will feel surprised, but that is because the dynamic controls that recreate them in the online method require the value they submit. Any control created after this method, although it can restore ViewState, but cannot get the value they submit and cannot trigger any changes.
The next method is RaiseChangeDevents, which is also performed after postbacks, and is also the private method of the page base class and cannot be overloaded. This is when the change event in the page life cycle is based on the difference before and after the submission value labeled in the ProcessPostData method. You can also call the validate method and check if it is valid. There is no guarantee for changing the order of changing events.
The next method is RaisePostBacke, which is also performed after postbacks, and is also a private method of the page base class and cannot be overloaded. Here is where except for automatic submission, the typical button or use JavaScript to submit a form with JavaScript. If it is not manually submitted, the validate is called by the verification control. Note that an IE's bug is sometimes not triggered when the Enter key is allowed to submit a form.
The next execution page method is onprender, which is the chance of the last impact page and its controls before the page presents before the client browser. You can also create dynamic controls in this method. The method of all this control will be executed to catch up, including viewState, but the previous private method will not perform another, which means that this control will not be recovered. No events of this control will not cause. Since IE's bug, this is a great place to capture a Postback without an event.
Save and present
The next method of execution is whether or not Postback's SaveViewState, this method is recursively executed by each control and its sub-control to generate ViewState. ViewState is mainly saved whether it is changed in the code or the user change is different from the attribute value defined in the ASPX page. Note that the control value is saved according to their position in the control tree, so if the dynamic control is later added, ViewState may be destroyed.
The next method is to save the SavePageStateTopersistenceMedium of the page ViewState. In order to replace the hidden domain to save ViewState with session or custom storage methods, this method will be overloaded along with LoadPageStateFromPersistenceMedium. This is useful for low-bandwidth scenarios, and the mobile page is the session. Looking at the code for detailed information in the related article, pay attention to a bug request in ASP.NET to send a _ViewState hidden domain, even if it is empty.
The render method of the page is then executed, all controls and its sub-controls are recursively executed, and eventually generate and send HTML to the browser. This method is used in some pages to add a usual page header and footer, which usually adds to the server-side control. This usually has some additional overhead. Note Because the control has been generated at this time, the change here must be pure HTML. You can use StringBuilder, StringWrite, and HTMLTextWriter to capture the output HTML. The real last execution method is ONUNLOAD, which also calls the Dispose method. This method allows you to clear the resources that are useless in the clear page, typically close any open files or turn off the previously opened database connection. Note that this method is only performed after the page has been sent to the client's browser, so it only affects the objects of the server, and does not appear in the page trace. This is the life cycle of the page - every new request is all reappeared.
Listing 1: Page Events Summary
MethodPostbackControls
ConstructoralwaysAlladdparsedSubbjectAlwaysAllDeeesetPostbackModeAlwaySpageonInitalwaySall
LoadpagestateFromPersistencemediumPostBackPageLoadViewStatePostBackAllProcessPostData1PostBackPageonLoadalwaysll
ProcessPostData2PostBackPageraiseChangeDeventspostbackPageraisePostBackeVentPostBackPageonPrenendralwaySall
SaveViewStateAlwaysallsavepagestateTopersistenceeMediumalwaySpagerendralwaySallonunloyadalwaySall
Other related articles: http: //authors.aspalliance.com/aldotnet/examples/plediagram.htmhttp: //msdn.microsoft.com/asp.net/default.aspx? Pull = / library / en-us / DNASP / HTML /ASPNET-PAGEOBJECTMODEL.ASPHTTP: //weblogs.asp.net/eporter/archive/2003/07/15/10109.aspxhttp://pluralsight.com/blogs/fritz/archive/2004/11/3544.aspx
