Translator: JOISE.LI)
Author: Paul Wilson
Translator:
Everyone knows that in the ASP.NET on the web programming, it is very useful to perform the execution order of each event in the page, which can be targeted to put their own handles in the specified location to achieve the correct result. This article describes the whole process incident from the initialization to the display. I saw it later, so I was translated into all the people, translating a lot of forgiveness. If you need to read the original item here.
l initialization
2 When the page is submitted, the first method is always constructed. You can initially initiate some custom attributes or objects in the constructor, but this time because the pages have not been fully initialized, there will be some restrictions. In particular, you need to use HTTPCONTEXT objects. The objects currently can use include QueryString, Form, and Cookies collection, as well as cache objects. Note: Session is not allowed in the constructor.
2 The next method will be executed is the AddParsedSubObject method, this method will add all separate controls and make the page into a control set tree, which is often overridden by some advanced page template solutions to add page content. In some special controls in the page template (Page Template). This method recursively applies to all page controls and each sub-control, all controls start initialization in this method.
2 The next method in the page class will be executed is DeterminePostBackMode. This method allows you to modify the value of IsPostBack and related events. If you need to load ViewState from the database, it will be particularly useful because viewState is only recovered if ISPostback is true. Returning to empty will result in forced to perform non-return, return request.form to force an email. Unless otherwise, it is not recommended to operate, because this will also affect other events.
2 The next method to be executed is the OnNit method, generally this is the first method that is truly used. When this method is triggered, the controls in all page definitions perform initialization, which means all values defined in the page apply to the appropriate controls. However, the value of ViewState and the report will not be applied to the control, so any value changed by code or user has not been restored to the control. This method is usually the best creation, re-creation of dynamic controls.
l Restore and loading
2 Next method, LoadPageStateFromPersistencemedium will only be executed when the page is passed back. If you modify the method SavePageStateTopersistencemedium that will be rewritten because you have modified the method SavePageStateToPersistencemedium that will be mentioned later will be mentioned later. The default implementation ViewState is a base64 format code and is saved in the hidden domain of the page, and you can use the methods mentioned in this article to modify the ViewState to save it in the above two ways. Note: This method does not really load the ViewState to the page or page control.
2 After getting ViewState, the next method loadViewsate will restore ViewState to the page and each page control or child control in a recursive manner. After this method is executed, each control will be restored to the last state, but the data submitted by the user has not been applied to the control because they are not part of ViewState. This method is mainly used to recover the values of the dynamically generated controls in other events, and their values are manually saved in viewsate and have now been invalid. 2 The next method is ProcessPostData, which is also the same as the return, and it is not allowed to be rewritten, this is a private method of the page base class. This method restores the value of the corresponding user submitted by matching the control, which means that the entire page has been completely restored. The only thing to remember is that all dynamic controls must be before this method. This method is also a method of recording a change event.
2 The next method is an OnLoad method, usually this is the most used method, because this method is where the page survival is the first place to restore all values. Most code decides whether to reset the control status based on judgment ispostback. You can also call validate in this method and check the value of IsValid. Dynamic controls can also be created in this method, and all methods of the control are executed to catch up with the status of the current page including viewsate, but does not include the return value.
l Event processing
2 Next method or processpostdata, it is actually another call for the previous method, which is still only executed while passing and is not overwritten because it is a private method. If you are the first time you look at the page, you will feel that this method has some extra. But in fact, this method is necessary because the dynamic controls created in ONLOAD also need them to return the value. Any control created later will be able to get their viewState, but can no longer get the value of their backhaul and do not trigger any value change events (CHANGE EVENT).
2 Next method, RaiseChangeDevents, is also executed only in the return page, and because all the private methods of the base class cannot be inherited. In the entire page survival period, the value change event is triggered by the value of the controls recorded by the previous ProcessPostData records. You may need to call Validate or check the value of IsValid. There is no particular explanation of the execution order of the plurality of values change events.
2 Next method, RaisePostBackevent, which is also because it is the private method of the base class cannot be inherited, and it is also only implemented in the return page. Unless used autopostback, this is where the actual submission of the form event is executed, especially the button or actually using JavaScript submission form. If you have not been called manually, Validate will be called. Note that there is a bug in IE sometimes allow submissions but do not trigger any events.
2 The next method is OnPrender, usually this is the last chance of changing the page and its control before the client exhibits the page. You can also create dynamic controls in this method, and all methods are executed to catch up with the status of the current page includes viewsate, but the private method will not be executed, which means that there will be no return value and will not There is an event trigger. Due to the bug in IE, this is a good place for caught forward with Postback.
l Save and display
2 The next method is SaveViewState, whether it is a return page, will be recursively executed to save the page and all of its controls. ViewState Solifies all values that are different from the original value defined in the ASPX, whether it is changed by the code or the user. Note that the control value is saved according to the location of their control tree on the page, so if the dynamic control is later added to the wrong location, it will cause confusion. 2 The next method is the viewsate of SavePageStateTopersistencemedium's true Save page. This method is rewritten along with LoadPageStateFromPersistenceMediumg to save ViewState to Session or other custom data instead of hidden domains. This is very helpful for low-bandwidth users. And for mobile devices, the session is the default setting. Hereinafter, this article describes the specific details of using the above two ways. Note that there is a bug in ASP.NET: ASP.NET requires the __viewstate field, even if it is empty.
2 The next method is the render method, which is recursively created and transmits the HTML to the browser for the corresponding control. This method is rewritten by some page template solutions to add some universal page heads and foot without using server controls, they always have some extra things. Note that the modifications here can only use pure HTML because the control has been generated here. You can use StringBuilder, StringWriter, HTMLTextWriter to capture the corresponding HTML output.
2 The final method is onunload, this method calls the corresponding Dispose method. This method provides an opportunity to empty the non-hosting resources used in this page, such as closing the open file handle, previously opened database connections, etc. Note that this method is to execute after the page has been sent to the client, so it only affects the server object, and it does not display the display track of the page. This is the survival of the page, which is running for each request.
l Author brief introduction (omitted)
Table 1: Summary of page events
method
return
Control
Constructor
Always
All
AddParsedSubObject
Always
All
DeterminePostBackmode
Always
Page
Oninit
Always
All
LoadPagestateFromPersistencemedium
Postback
Page
LoadViewState
Postback
All
ProcessPostData1
Postback
Page
Online
Always
All
ProcessPostData2
Postback
Page
RaiseChangeDevents
Postback
Page
RaisePostBackevent
Postback
Page
OnPrender
Always
All
SaveViewState
Always
All
SavepagestateTopersistencemedium
Always
Page
Render
Always
All
ONUNLOAD
Always
All
