When it comes to building web applications ASP.NET 2.0 will make
life a lot easier. The key to success in building good web apps with
ASP 1.x lies in understanding the page lifecycle. Which still has a lot
of secrets and surprises. In this post I will investigate it once again
and cover some of my new findings.
The page life-cycle
On each roundtrip a webform is loaded in IIS and the events on the
page are fired. The sequence in which the events are fired is fixed.
The handling of the page request has three stages, each of
the stages has its own events. You can find most of them in the
property window of the forms designer.
These events are found not only on the webform itself but also on all the controls of the form.
- In the first part the page is initialized. First the init event is
fired. You can perform some initialization but its context (which
contains things like the request parameters) is not avaliable yet.
After this the page is loaded in IIS and the page-load event is fired.
Now the context and all the controls are available. VS generates an
empty event handler and advises you to write your initialization code
here.
private void Page_Load(object sender, System.EventArgs e)
{
// Put user code to initialize the page here
// For the sake of simplicity the database code is put here :< In real life this should be somewhere else !!
sqlConnection1.Open();
sqlDataAdapter1.Fill(dataSet11);
sqlConnection1.Close();
this.DataBind();
}
- In the second part of the cycle events like button clicks and
grid-link button clicks are handled. An eventhandler, like the click of
an update button, could change underlying data allready being read
in in the pageload. Now you have a problem.
- In the third part of the cycle the page will render the HTML
to the result which will be returned to the client. As a last resort
you can hook into the pre-render event. In case your buttons update the
data the prerender event is a better place to load the data
private void WebForm1_PreRender(object sender, System.EventArgs e)
{
// For the sake of simplicity the database code is put here. In real life this should be somewhere else.
sqlConnection1.Open();
sqlDataAdapter1.Fill(dataSet11);
sqlConnection1.Close();
this.DataBind();
}
Any updates caused by your buttonclicks are now visible on the page.
- After the prerender event the unload and dispose event are fired.
As you page no longer has a context you cannot do anything with the
pages content.
A control which is not visible is not rendered. As a consequence the
prerender event will not be fired on an invisible control. The
page_load event is allways fired. If you put your dataloading code in
the prerender event of the control consuming the data, your data will
not be read when it is not used. That’s another plus of the
prerender event.
The viewstate
This scenario works as described when the viewstate is enabled, as
it is by default. When you use a datagrid the viewstate can be quite
huge. In case the grid’s data are read in again on every roundtrip it
makes a lot of sense to disable the grid’s viewstate. This will higly
reduce the amount of data travelling over the wire.
Typical events in a datagrid are things like ItemCommand which fires whenever a linkbutton (with a commandname) in the grid is clicked. Like the select or Sort button. The SelecetedIndexChanged event will fire whenever a select button was clicked. Also when the SelectedIndex
has not changed in value. These events fire in the middle part of the
page, together with all the other button-clicks and the like.
When you disable the viewstate the behaviour of the grid can change
dramatically. In case the data is bound to the grid in the page_load,
which happens before the grid’s events, the grid will behave the same.
The events fire and even selectedindex has a usable value. But when you bind the data to the grid in the prerender event no events will fire at all and the SelectedIndexwill allways reads -1. Drilling down you will find that even OnBubbleEvent, which triggers the item events, does not fire. And there is nothing you can do about that.
Roundup
In an ideal situation I want the following
- Disable the viewstate of the datagrid
- Bind the data in the concluding part of the life cycle
- Use the selectedindex property
The last two points are in conflict. That’s why I started working on a custom datagrid
with a custom implementation of the Selectedindex. Which works for the
time being. ASP.NET 2.0 will bring relief: it generates all the
plumbing code needed to get my data in and out of the page and
introduces the controlstate which saves the essential state of the grid
without the hog.