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.

* 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 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 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). 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)

http://www.15seconds.com/issue/050721.htm