The Artima Developer Community
Sponsored Link

.NET Buzz Forum
Events in a datagrid, the page lifecycle and the viewstate

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Peter van Ooijen

Posts: 284
Nickname: petergekko
Registered: Sep, 2003

Peter van Ooijen is a .NET devloper/architect for Gekko Software
Events in a datagrid, the page lifecycle and the viewstate Posted: Apr 19, 2005 3:43 AM
Reply to this message Reply

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.
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Peter van Ooijen
Latest Posts From Peter's Gekko

Advertisement

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.

 

Read: Events in a datagrid, the page lifecycle and the viewstate

Topic: Java Watch: What’s Not Coming in Mustang Previous Topic   Next Topic Topic: Pitfalls when installing Visual Studio 2005 Beta 2 with Sql Server 2005 Beta 2?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use