NEWS

Thursday, June 28, 2012

Page Processing and events in asp.net


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 theoriginal 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
A more detailed explanation of the postback processing can be found in the "The ASP.NET Page Object Model - One Day in the Life of an ASP.NET Web Page" article.
"Learn about the eventing model built around ASP.NET Web pages and the various stages that a Web page experiences on its way to HTML. The ASP.NET HTTP run time governs the pipeline of objects that transform the requested URL into a living instance of a page class first, and into plain HTML text next. Discover the events that characterize the lifecycle of a page and how control and page authors can intervene to alter the standard behavior"
ViewState - the all mighty!
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.
"Understanding ASP.NET View State" looks at how an ASP.NET page maintains its state changes across postbacks, examining:
  • 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
Note: if you need to examine the ViewState while debugging, try the Page ViewState Parsers

8 comments: