PostBack  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).  As described initial page requests are relatively simple.  The real work gets done when a page is submitted to itself – and a postback request is generated.  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.

AutoPostBack Property  Along with common events such as click events on buttons, some page elements support postback events for things like selecting items in a list or changing the contents of a textbox.  Since these kinds of “secondary” events can happen quite frequently on a form, these events do not automatically cause event to fire on the server.  Instead you need to add a special attribute to the server control in order to make sure it will create a client-side event that will send a message back to the server for processing.  This special attribute is the AutoPostBack attribute.  In order to force these controls to fire events on the server, you need to set the AutoPostBack attribute to true.

Round Tripping  The web form model supports round - tripping between the client and the server.  In round – tripping, each time the user presses a button, the page is sent to the server, the inputs are interpreted at the server, the page is rebuilt, and then this rebuilt page is sent back to the client again.  This round – tripping continues whenever the user causes a client – side event to fire server side code.  In any Web scenario, web pages are recreated with every round trip.  When the server finishes processing and sends the page to the browser, it discards the page information.

 This frees server resources after each request and a web application can scale to support hundreds or thousands of simultaneous users.  The next time the page is posted, the server starts over in creating and processing it, and for this reason, web pages are said to be stateless.  Stateless means the value of a page’s variables and controls are not saved on the server.

Lifecycle Of a Web Page

Object Initialization  The first stage in 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.  At this point the controls have no attributes or properties.  ViewState information is not available at this stage.

Load ViewState Data  After the Init event, controls can be referenced using their IDs only.  At LoadViewState event, the initialized controls receive their first properties: viewstate information that was persisted back to the server on the last submission.  The page viewstate is managed by ASP.NET and is used to persist information over a page roundtrip to the server.

LoadPostData Processes PostBackData  During this phase of the page creation, form data that was posted to the server (termed postback data) is processed against each control that requires it.  When a page submits a form, the framework will implement the IPostBackDataHandler interface on each control that submitted data.  The page then fires the LoadPostData event and parses through the page to find each control that implements this interface and updates the control state with the correct postback data.

Object Load  Objects take true form during the Load event.  All object are first arranged in the page DOM (called the Control Tree in ASP.NET) and can be referenced easily through code or relative position (crawling the DOM).  If this is the first time the page is being processed (Page.IsPostBack property), initial data binding is performed here.  This stage is where the majority of work happens.  The Load event can be overridden by calling OnLoad.

Raise PostBack Change Events  “Change” events are fired for controls (TextChanged, SelectedIndexChanged, & similar).  The current value (from PostData) is compared to the original value located in the viewState.  If there is a difference “changed” events are raised.

Process Client-Side PostBack event  After the server-side events fire on data that was changed due to postback updates, the object which caused the postback is handled at the RaisePostBackEvent event.  There is often code that will execute in this event, as this is an ideal location to handle event-driven logic.  If validation controls present on the page, server side events are fired for any validation controls.

PreRender the Objects  The point at which the objects are prerendered is the last time changes to the objects can be saved or persisted to viewstate.  This makes the PreRender step a good place to make final modifications, such as changing properties of controls or changing Control Tree structure, without having to worry about ASP.NET making changes to objects based off of database calls or viewstate updates.

ViewState Saved  The viewstate is saved after all changes to the page objects have occurred.  Object state data is persisted in the hidden object.  At the SaveViewState event, values can be saved to the ViewState object, but changes to page controls are not.

Render to HTML  The Render event commences the building of the page by assembling the HTML for output to the browser.  During the Render event, the page calls on the objects to render themselves into HTML.  The page then collects the HTML for delivery.  Changes can still be made at this point, but they are reflected to the client only.

Disposal/Unload  After the page's HTML is rendered, the objects are disposed of.  During the Dispose event, you should destroy any objects or references you have created in building the page.  At this point, all processing has occurred and it is safe to dispose of any remaining objects, including the Page object.