Lesson 2: Responding to Events

The purpose of this lesson is detail Web application events from the page level to the application level. Dino Esposito further details the sequential, cyclical process of page-level events in "The ASP.NET Page Object Model: One Day in the Life of an ASP.NET Web Page" here:

http://msdn.microsoft.com/library/en-us
    /dnaspp/html/aspnet-pageobjectmodel.asp

• "The life of a Web application begins when a browser requests the start page of the application."

This statement does not seem accurate. The assumption here is that the life of a Web application begins when a browser requests any page of the application. This level of accuracy takes into account what some call "deep linking."

• "When the user stops using the Web application for a period of time (the default is 20 minutes), the user's session times out and ends."

When all sessions end the application "ends" but because of .NET Framework garbage collection, "...you don't know when an Application_End event will occur." For more details about Session State, see "Session State" at MSDN:

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconSessionState.asp

• "The data that ASP.NET preserves between requests is called the Web form's view state."

This introduction of view state seems to serve only to introduce the words "view state" as the lesson moves on quickly to survey Application and Session "state variables" (yet another term that understandably avoids delving into the object collections of the underlying HttpApplicationState and HttpSessionState classes). More details at MSDN in "ASP.NET State Management" here:

http://msdn.microsoft.com/library/
    en-us/cpguide/html/cpconaspstatemanagement.asp

• "Application state variables must be initialized in Visual C#..."

The assumption here is that C# does not protect the developer against runtime errors caused by strong-typing collections of type object with casting. The code samples on page 3 clearly suggest that VB.NET insulates the developer from such pitfalls.

• "You can write code to respond to Application and Session events in the Global.asax file."

The following summarizes application-scope event handlers:

Application_Start
Application_End
Application_BeginRequest
Application_EndRequest

Session_Start
Session_End

• "In Web forms, a session is a unique instance of the browser."

The following summarizes the page-scope event handlers firing in sequence:

Page_Init
Page_Load
Page_PreRender
Page_Unload
Page_Disposed

The following summarizes the other page-scope event handlers:

Page_Error
Page_AbortTransaction
Page_CommitTransaction
Page_DataBinding

• "You can couple the Page_Load event with the IsPostBack property to initialize data the first time a user visits a Web form."

The following summarizes the server control-scope event types:

Postback events (e.g. the Click event)
Cached events (e.g. the TextChanged event; see below)
Validation events (solely of the validation server controls)

The lesson refers to "Cached events" for the sake of completeness but not clarity. This term should not be confused with "cache events": Cache events are not really .NET Framework events but are a design pattern featuring the CacheItemRemovedCallback delegate. This is discussed in detail in Chapter 12, "Optimizing Web Applications with Caching" under "Responding to Cache Events."

Cached events reveal the design goal of the ASP.NET team to try as much as possible to replicate Windows Forms eventing by "postponing" events on the client and processing them later on the server.