Processing Page Requests
When an initial request for a page (a Web Form) is received by ASP.NET, it locates and loads the requested Web Form (and if necessary compiles the code). It is important to understand the sequence of events that occurs when a Web Forms page is processed. This knowledge will help you program your Web Forms pages and Web applications more effectively.
As described before, initial page requests are relatively simple. The real work gets done when a page is submitted to itself - and a postback request is generated. Here are a few notes on postback requests:
* The current value of every control on a Web Form is contained in the postback request. This is referred to as the Post Data
* The content of the ViewState is also contained in the Post Data. ViewState holds the original property values of every control on a Web Form - before the user made any changes
* If a postback was caused, for example, by a button click, Post Data is used to identify the button that caused the postback
Postback Event Processing Sequence
Here are the events (and the order) that are raised when a Button is clicked and a postback occurs:
1. Page.Init + Control.Init for every control on the Web Form
The first stage in the page life cycle is initialization. After the page's control tree is populated with all the statically declared controls in the .aspx source the Init event is fired. First, the Init event for the Page object occurs, then Init event occurs for each control on the Page. Viewstate information is not available at this stage.
2. Page.LoadViewState
After initialization, ASP.NET loads the view state for the page. ViewState contains the state of the controls the last time the page was processed on the server.
3. Page.ProcessPostData
Post Data gets read from the request and control values are applied to control initalized in stage 1.
4. Page.Load + Control.Load for each control on the Page
If this is the first time the page is being processed (Page.IsPostback property), initial data binding is performed here.
5. "Change" events are fired for controls (TextChanged, SelectedIndexChanged, and similar)
The current value (from Post Data) is compared to the original value located in the ViewState. If there is a difference "Changed" events are raised.
6. Server-side events are fired for any validation controls
7. Button.Click + Button.Command
The Click and Command events are fired for the button that caused the postback
8. Page.PreRender + Control.PreRender
9. Page.SaveViewState
New values for all the controls are saved to the view state for another round-trip to the server.
10. Page.Render
As you can see from the postback steps, the ViewState has a major role in ASP.NET. Viewstate is a collection of name/value pairs, where control's and page itself store information that is persistent among web requests.
* The ASP.NET Page Life Cycle
* The Role of View State
* The Cost of View State
* How View State is Serialized/Deserialized
* Specifying Where to Store the View State Information (see how to store it in a file on the Web server rather than as a bloated hidden form field)
* Programmatically Parsing the View State
* View State and Security Implications
Follow the MSDN link to read more
http://msdn.microsoft.com/en-us/library/ms972976
No comments:
Post a Comment