This post originated from an RSS feed registered with .NET Buzz
by Peter van Ooijen.
Original Post: Events in a datagrid, the page lifecycle and the viewstate
Feed Title: Peter's Gekko
Feed URL: /error.htm?aspxerrorpath=/blogs/peter.van.ooijen/rss.aspx
Feed Description: My weblog cotains tips tricks and opinions on ASP.NET, tablet PC's and tech in general.
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 !!
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.