The ASP.

NET Page Life Cycle Introduction
When a page request is sent to the Web server, whether through a submission or location change, the page is run through a series of events during its creation and disposal. When we try to build ASP.NET pages and this execution cycle is not taken into account, we can cause a lot of headaches for ourselves. However, when used and manipulated correctly, a page's execution cycle can be an effective and powerful tool. Many developers are realizing that understanding what happens and when it happens is crucial to effectively writing ASP.NET pages or user controls. So let's examine in detail the ten events of an ASP.NET page, from creation to disposal. We will also see how to tap into these events to implant our own custom code.

1. Object Initialization
A page's controls (and the page itself) are first initialized in their raw form. By declaring your objects within the constructor of your C# code-behind file (see Figure 1), the page knows what types of objects and how many to create. Once you have declared your objects within your constructor, you may then access them from any sub class, method, event, or property. However, if any of your objects are controls specified within your ASPX file, at this point the controls have no attributes or properties. It is dangerous to access them through code, as there is no guarantee of what order the control instances will be created (if they are created at all). The initialization event can be overridden using the OnInit method.

2. Load Viewstate Data
After the Init event, controls can be referenced using their IDs only (no DOM is established yet for relative references). 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. Viewstate information is saved as a string of name/value pairs and contains information such as control text or value. The viewstate is held in the value property of a hidden <input> control that is passed from page request to page request. As you can see, this is a giant leap forward from the old ASP 3.0 techniques of maintaining state. This event can be overridden using the LoadViewState method and is commonly used to customize the data received by the control at the time it is populated. Figure 2 shows an example of overriding and setting viewstate at the LoadViewState event

3. LoadPostData Processes Postback Data
During this phase of the page creation, form data that was posted to the server (termed postback data in ASP.NET) 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. ASP.NET updates the correct control by matching the control's unique ID with the name/value pair in the NameValueCollection. This is one reason that ASP.NET requires unique

this occurs after all controls that implement the IPostBackDataHandler interface have been updated with the correct postback data. 6. This stage is where the majority of work happens. each control is flagged with a Boolean on whether its data was actually changed or remains the same since the previous submit. coded logic. Objects are then free to retrieve the client-side properties set in the HTML. such as several custom user controls existing on a single page.NET) and can be referenced easily through code or relative position (crawling the DOM). During Load. the object which caused the postback is handled at the RaisePostBackEvent event. such as changing properties of controls or changing Control Tree structure. as this is an ideal location to handle event-driven logic. 4.NET making changes to objects based off of database calls or viewstate updates. Extra steps are taken by the framework to ensure each ID is unique in situations. After the PreRender phase those changes to objects are locked in and can no longer be saved to the page viewstate. and using the StringBuilder to assemble a string for output. 5. The RaisePostDataChanged event does not fire until all controls are updated and after the Load event has occurred. The RaisePostBackEvent event fires last in the series of postback events due to the accuracy of the data that is rendered to the browser 7. There is often code that will execute in this event. Process Client-Side PostBack Event After the server-side events fire on data that was changed due to postback updates. such as width. Raise PostBack Change Events As stated earlier.IDs for each control on any given page. without having to worry about ASP. ASP. The PreRender step can be overridden using OnPreRender . This ensures data in another control is not manually altered during the RaisePostDataChanged event before it is updated with postback data. or visibility. setting control properties programmatically. All object are first arranged in the page DOM (called the Control Tree in ASP. value.NET then sweeps through the page looking for flags indicating that any object's data has been updated and fires RaisePostDataChanged. is also executed. This makes the PreRender step a good place to make final modifications. The offending object is usually a control that posted the page back to the server due to a state change (with autopostback enabled) or a form submit button that was clicked. 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. Object Load Objects take true form during the Load event. such as arithmetic. During this operation.

Object state data is persisted in the hidden <input> object and this is also where object state data is prepared to be rendered to HTML. . By understanding the inner workings of the ASP. but they are reflected to the client only 10. You can override this step by using SaveViewState 9. all processing has occurred and it is safe to dispose of any remaining objects. When the Render event is overridden. you should destroy any objects or references you have created in building the page. Render To HTML The Render event commences the building of the page by assembling the HTML for output to the browser.NET page process. we run through the same process from initialization to disposal. the objects are disposed of. At the SaveViewState event. During the Render event. but changes to page controls are not. The page then collects the HTML for delivery. During the Dispose event.NET page.8. At this point. ViewState Saved The viewstate is saved after all changes to the page objects have occurred. Conclusion Each time we request an ASP. Changes can still be made at this point. including the Page object. The Render method takes an HtmlTextWriter object as a parameter and uses that to output HTML to be streamed to the browser. writing and debugging our code will be much easier and effective (not to mention less frustrating). values can be saved to the ViewState object. the developer can write custom HTML to the browser that nullifies all the HTML the page has created thus far. Disposal After the page's HTML is rendered. the page calls on the objects to render themselves into HTML.