Dev Basics: ASP.NET Page Life Cycle, Part 1 [Events]
• Jay Harris
When a request occurs for an ASP.NET page, the response is processed through a series of events before being sent to the client browser. These events, known as the ASP.NET Page Life Cycle, are a complicated headache when used improperly, manifesting as odd exceptions, incorrect data, performance issues, and general confusion. It seems simple when reading yet-another-book-on-ASP.NET, but never when applied in the real world. What is covered in a few short pages in many ASP.NET books (and sometimes even just a few short paragraphs), is much more complicated outside of a "Hello, World!" application and inside of the complex demands of the enterprise applications that developers create and maintain in their day-to-day work life. As close to the core as the life cycle is to any ASP.NET web application, the complications and catches behind this system never seems to get wide coverage on study guides or other documentation. But, they should.
Posts in this Series
Part 1: Events of the ASP.NET Page Life Cycle
Part 2: ASP.NET Page & WebControl Event Execution
Part 3: Getting Started with ASP.NET DataBinding
Part 4: Wiring Events to Your Page
A little help on the Page Life Cycle is never a bad thing. In this series, I will go over the events that make up the ASP.NET Page Life Cycle, as well as some tips and tricks on how to get the most out of this event structure while avoiding the traps and pitfalls. Rather than pursuing broad coverage of the entire ASP.NET Framework, we'll dive deeply into the "small" portion that is the ASP.NET Page Life Cycle.
Events of the ASP.NET Page Life Cycle
I want to start at the beginning. The primary make-up of the Page Life Cycle is the events that process any ASP.NET requests. Unlike the
public static void main of a WinForms application, where everything based on methods, the execution of a page request is the execution of these events. These events, which execute in a particular order, handle the entire request, including loading all of the controls, processing all of the form data, handling all user-initiated actions, and rendering the page to the web browser. Knowing the order in which these events are executed, as well as the responsibility of each event in processing your request, is important for developing solid, quality ASP.NET applications.
This is where the page object is instantiated, and where the initial properties of the page are set. Page properties such as
UICulture (similar to the
UICulture property within a WinForms thread), and the value of
IsPostBack are all determined and assigned. No controls are available at this time, so do not try to set the value of that
TextBox control, as it doesn't exist, yet. Fortunately, no event handlers can be attached to this event, anyway, so there isn't much you can do to customize this processing or to access that TextBox's value property; "Move along. There is nothing to see here." But, be aware that this event does occur after the Constructor, so if you try to access properties such as
IsPostBack prior to the
Start event, they have yet to be assigned, and will likely be incorrect.
During page initialization, the controls are created, initialized, and added to the Page's controls collection. This is the first time that you can access a control by its
UniqueID. Do note that all control properties are set to their code values, be it from code-behind or code-in-front, regardless of what may be available in ViewState and Form Post values. Control state has yet to be restored, so ViewState and Form Post values have not yet been pushed to the controls. Finally, Initialization (specifically,
PreInit) is the only time that the Theme and Master Page can be programmatically modified.
Load is where control state is restored. If the request is a
PostBack, rather than a new request, all available property values are restored from ViewState and Form Post data and pushed to the applicable controls. Under most scenarios, this is where you're going to get what you need from the Database, such as pulling a value from the query string and loading an item with the matching identity.
Validation event only applies to
PostBack requests, and only when Validators are present in the control collection. The
Validate method is executed for each Validator present, through which the
IsValid property is set for each Validator. These
IsValid property values are then cascaded up to the Page's
IsValid property. Be aware that even if all Validators on the page are disabled, the Validation event will still fire; if a Validator is present, Validate is executed, without regard to any other property. Also, note that the Validation event is a child of the Page's
Load event, so it is executed within the Page Load event chain, after Page Load, but prior to
PostBack Events and
Once Validation is complete (if applicable), all
PostBack events are executed, including the
OnChange event of a
DropDownList and the
OnClick event of a command button. Post Back Events are also a child of the Page's
Load event, executing after
Validation and before
Finally, once all of the data is processed and Post Back events handled, the Page is rendered within the Web Browser. The
Render event consists of saving all control property data to ViewState, processing the Page and each Control into HTML, and writing the HTML to the output stream. This is the last opportunity to modify the HTML output.
Remember the Order
If you are having trouble remembering the order, instead try to remember this simple mnemonic:
SILVER—Start, Initialize, Load, Validation, Events, Render.
If you are doing a lot of ASP.NET programming, or anticipate that you will be in the near future, try to commit to memory the order of each of these events, and their scope of influence. Understanding these basic fundamentals of the ASP.NET Page Life Cycle will help ensure that you are executing your custom code at the right time, and in the right order, rather than stepping on yourself by conflicting with the core functionality.
Now that we know the order of execution on Page Events, what is the order of the Controls? Does
Page.Load execute before
Control.Load? How about the order of sibling controls? What is the order of
myTextBox2.TextChanged? Also, what are some things to look out for? As this series continues, we will discuss the details of event execution order within the ASP.NET Page Life Cycle, as well as some tips, tricks, and traps when developing ASP.NET applications.