The ASP.

NET Page Life Cycle

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.
I'll set the stage with a simple submission form written in ASP.NET with C#. The page is loaded
for the first time and has several server-side Web controls on it. When the Web server receives a
request for the page, it will process our Web controls and we will eventually get rendered HTML.
The first step in processing our page is object initialization.

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.

Figure 1: - Controls are initialized based on their declaration.

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.
Figure 2: - When LoadViewState is fired, controls are populated with the appropriate viewstate
data.

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 IDs
for each control on any given page. Extra steps are taken by the framework to ensure each ID is
unique in situations, such as several custom user controls existing on a single page. After the
LoadPostData event triggers, the RaisePostDataChanged event is free to execute (see below).

4. Object Load
Objects take true form during the Load event. All objects 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). Objects are then free to retrieve the client-side properties set in the HTML,
such as width, value, or visibility. During Load, coded logic, such as arithmetic, setting control
properties programmatically, and using the StringBuilder to assemble a string for output, is also
executed. This stage is where the majority of work happens. The Load event can be overridden by
calling OnLoad as shown in Figure 3.

Figure 3 - The OnLoad event is an ideal location to place logic.

5. Raise PostBack Change Events

As stated earlier, this occurs after all controls that implement the IPostBackDataHandler interface
have been updated with the correct postback data. During this operation, each control is flagged
with a Boolean on whether its data was actually changed or remains the same since the previous
submit. ASP.NET then sweeps through the page looking for flags indicating that any object's data
has been updated and fires RaisePostDataChanged. The RaisePostDataChanged event does not
fire until all controls are updated and after the Load event has occurred. This ensures data in
another control is not manually altered during the RaisePostDataChanged event before it is
updated with postback data.

6. 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. 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. There is often code that will
execute in this event, as this is an ideal location to handle event-driven logic. The
RaisePostBackEvent event fires last in the series of postback events due to the accuracy of the
data that is rendered to the browser.
Controls that are changed during postback should not be updated after the executing function is
called due to the consistency factor. That is, data that is changed by an anticipated event should
always be reflected in the resulting page. The RaisePostBackEvent can be trapped by catching
RaisePostBackEvent, as in Figure 4.

Figure 4 - The RaisePostDataChanged and RaisePostBackEvent events are defined by the

IPostBackDataHandler interface.

7. 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. After the PreRender phase those changes to objects are locked in and can no
longer be saved to the page viewstate. The PreRender step can be overridden using OnPreRender

8. ViewState Saved
The viewstate is saved after all changes to the page objects have occurred. 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. At the SaveViewState event, values can be saved to the ViewState object, but
changes to page controls are not. You can override this step by using SaveViewState, as shown in
Figure 5.
Figure 5: - Values are set for controls in OnPreRender. During the SaveViewState event, values
are set for the ViewState object.

9. 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. When the Render event is overridden, the developer
can write custom HTML to the browser that nullifies all the HTML the page has created thus far.
The Render method takes an HtmlTextWriter object as a parameter and uses that to output HTML
to be streamed to the browser. Changes can still be made at this point, but they are reflected to
the client only. The Render event can be overridden, as shown in Figure 6 (below).

10. Disposal
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. You can override Dispose, as shown in Figure 6.

Figure 6 - The Render event will output custom HTML to the browser through the HtmlTextWriter
object.

Conclusion
Each time we request an ASP.NET page, we run through the same process from initialization to
disposal. By understanding the inner workings of the ASP.NET page process, writing and
debugging our code will be much easier and effective (not to mention less frustrating).