The ASP.NET Page Life Cycle


Nov 5, 2013 (4 years and 8 months ago)


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
s 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 c

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 a
nd we will eventually get rendered HTML. The first step in
processing our page is object initialization.

download source code

view demo

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 cr
eate. 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 att
ributes 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 es
tablished 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 use
d 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 tha
t 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
d 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 LoadVie
wState 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 ea
ch 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 i
mplements 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 uni
que 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 ev
ent is free to execute (see

4. 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 t
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. Durin
g 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 f
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 up
dated 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 u
sually 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 lo
gic. 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 th
e 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

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
king 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. ViewStat
e 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 Rend
er 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 t
hus 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
ed 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 w
ill output custom HTML to the browser through the HtmlTextWriter


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, wr
iting and debugging our code will
be much easier and effective (not to mention less frustrating).