asp page lifecycle

ASP.NET Page Life Cycle Overview

When an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps. These include initialization, instantiating controls, restoring and maintaining state, running event handler code, and rendering. It is important for you to understand the page life cycle so that you can write code at the appropriate life-cycle stage for the effect you intend. Additionally, if you develop custom controls, you must be familiar with the page life cycle in order to correctly initialize controls, populate control properties with view-state data, and run any control behavior code. (The life cycle of a control is based on the page life cycle, but the page raises more events for a control than are available for an ASP.NET page alone.)

General Page Life-cycle Stages

In general terms, the page goes through the stages outlined in the following table. In addition to the page life-cycle stages, there are application stages that occur before and after a request but are not specific to a page. Page request The page request occurs before the page life cycle begins. When the page is requested by a user, ASP.NET determines whether the page needs to be parsed and compiled (therefore beginning the life of a page), or whether a cached version of the page can be sent in response without running the page. Start In the start step, page properties such as Request and Response are set. At this stage, the page also determines whether the request is a postback or a new request and sets the IsPostBack property. Additionally, during the start step, the page's UICulture property is set. Page initialization During page initialization, controls on the page are available and each control's UniqueID property is set. Any themes are also applied to the page. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state. Load During load, if the current request is a postback, control properties are loaded with information recovered from view state and control state. Validation During validation, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page. Postback event handling If the request is a postback, any event handlers are called. Rendering Before rendering, view state is saved for the page and all controls. During the rendering phase, the page calls the Render method for each control, providing a text writer that writes its output to the OutputStream of the page's Response property. Unload Unload is called after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and any cleanup is performed.

Life-cycle Events

Within each stage of the life cycle of a page, the page raises events that you can handle to run your own code. For control events, you bind the event handler to the event, either declaratively using attributes such as onclick, or in code.

Pages also support automatic event wire-up, meaning that ASP.NET looks for methods with particular names and automatically runs those methods when certain events are raised. If the AutoEventWireup attribute of the @ Page directive is set to true (or if it is not defined, since by default it is true), page events are automatically bound to methods that use the naming convention of Page_event, such as Page_Load and Page_Init.

The following table lists the page life-cycle events that you will use most frequently. There are more events than those listed; however, they are not used for most page processing scenarios. Instead, they are primarily used by server controls on the ASP.NET Web page to initialize and render themselves. If you want to write your own ASP.NET server controls, you need to understand more about these stages.

Page Event	Typical Use
PreInit	Use this event for the following: Check the IsPostBack property to determine whether this is the first time the page is being processed. Create or re-create dynamic controls. Set a master page dynamically. Set the Theme property dynamically. Read or set profile property values. Note If the request is a postback, the values of the controls have not yet been restored from view state. If you set a control property at this stage, its value might be overwritten in the next event.
Init	Raised after all controls have been initialized and any skin settings have been applied. Use this event to read or initialize control properties.
InitComplete	Raised by the Page object. Use this event for processing tasks that require all initialization be complete.
PreLoad	Use this event if you need to perform processing on your page or control before the Load event. After the Page raises this event, it loads view state for itself and all controls, and then processes any postback data included with the Request instance.
Load	The Page calls the OnLoad event method on the Page, then recursively does the same for each child control, which does the same for each of its child controls until the page and all controls are loaded. Use the OnLoad event method to set properties in controls and establish database connections.
Control events	Use these events to handle specific control events, such as a Button control's Click event or a TextBox control's TextChanged event. In a postback request, if the page contains validator controls, check the IsValid property of the Page and of individual validation controls before performing any processing.
LoadComplete	Use this event for tasks that require that all other controls on the page be loaded.
PreRender	Before this event occurs: The Page object calls EnsureChildControls for each control and for the page. Each data bound control whose DataSourceID property is set calls its DataBind method. The PreRender event occurs for each control on the page. Use the event to make final changes to the contents of the page or its controls.
SaveStateComplete	Before this event occurs, ViewState has been saved for the page and for all controls. Any changes to the page or controls at this point will be ignored. Use this event perform tasks that require view state to be saved, but that do not make any changes to controls.
Render	This is not an event; instead, at this stage of processing, the Page object calls this method on each control. All ASP.NET Web server controls have a Render method that writes out the control's markup that is sent to the browser. If you create a custom control, you typically override this method to output the control's markup. However, if your custom control incorporates only standard ASP.NET Web server controls and no custom markup, you do not need to override the Render method. A user control (an .ascx file) automatically incorporates rendering, so you do not need to explicitly render the control in code.
Unload	This event occurs for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections. For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks. Note During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.

Additional Page Life Cycle Considerations

Individual ASP.NET server controls have their own life cycle that is similar to the page life cycle. For example, a control's Init and Load events occur during the corresponding page events.

Although both Init and Load recursively occur on each control, they happen in reverse order. The Init event (and also the Unload event) for each child control occur before the corresponding event is raised for its container (bottom-up). However the Load event for a container occurs before the Load events for its child controls (top-down).

You can customize the appearance or content of a control by handling the events for the control, such as the Click event for the Button control and the SelectedIndexChanged event for the ListBox control. Under some circumstances, you might also handle a control's DataBinding or DataBound events.

When inheriting a class from the Page class, in addition to handling events raised by the page, you can override methods from the page's base class. For example, you can override the page's InitializeCulture method to dynamically set culture information. Note that when creating an event handler using the Page_event syntax, the base implementation is implicitly called and therefore you do not need to call it in your method. For example, the base page class's OnLoad method is always called, whether you create a Page_Load method or not. However, if you override the page OnLoad method with the override keyword (Overrides in Visual Basic), you must explicitly call the base method. For example, if you override the OnLoad method on the page, you must call base.Load (MyBase.Load in Visual Basic) in order for the base implementation to be run.

Catch-up Events for Added Controls

If controls are created dynamically at run time or are authored declaratively within templates of data-bound controls, their events are initially not synchronized with those of other controls on the page. For example, for a control that is added at run time, the Init and Load events might occur much later in the page life cycle than the same events for controls created declaratively. Therefore, from the time that they are instantiated, dynamically added controls and controls in templates raise their events one after the other until they have caught up to the event during which it was added to the Controls collection.

In general, you do not need to be concerned about this unless you have nested data-bound controls. If a child control has been data bound, but its container control has not yet been data bound, the data in the child control and the data in its container control can be out of sync. This is true particularly if the data in the child control performs processing based on a data-bound value in the container control.

For example, suppose you have a GridView that displays a company record in each row along with a list of the company officers in a ListBox control. To fill the list of officers, you would bind the ListBox control to a data source control (such as SqlDataSource) that retrieves the company officer data using the CompanyID in a query.

If the ListBox control's data-binding properties, such as DataSourceID and DataMember, are set declaratively, the ListBox control will try to bind to its data source during the containing row's DataBinding event. However, the CompanyID field of the row does not contain a value until the GridView control's RowDataBound event occurs. In this case, the child control (the ListBox control) is bound before the containing control (the GridView control) is bound, so their data-binding stages are out of sync.

To avoid this condition, put the data source control for the ListBox control in the same template item as the ListBox control itself, and do not set the data binding properties of the ListBox declaratively. Instead, set them programmatically at run time during the RowDataBound event, so that the ListBox control does not bind to its data until the CompanyID information is available.

Data Binding Events for Data-Bound Controls

To help you understand the relationship between the page life cycle and data binding events, the following table lists data-related events in data-bound controls such as the GridView, DetailsView, and FormView controls.

Control Event	Typical Use
DataBinding	This event is raised by data-bound controls before the PreRender event of the containing control (or of the Page object) and marks the beginning of binding the control to the data. Use this event to manually open database connections, if required. (The data source controls often make this unnecessary.)
RowCreated (GridView only) or ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, and Repeater controls)	Use this event to manipulate content that is not dependent on data binding. For example, at run time, you might programmatically add formatting to a header or footer row in a GridView control.
RowDataBound (GridView only) or ItemDataBound (DataList, SiteMapPath, DataGrid, and Repeater controls)	When this event occurs, data is available in the row or item, so you can format data or set the FilterExpression property on child data source controls for displaying related data within the row or item.
DataBound	This event marks the end of data-binding operations in a data-bound control. In a GridView control, data binding is complete for all rows and any child controls. Use this event to format data bound content or to initiate data binding in other controls that depend on values from the current control's content. (For details, see "Catch-up Events for Added Controls" earlier in this topic.)

Validating User Input in ASP.NET Web Pages 

You can add input validation to ASP.NET Web pages using validation controls. Validation controls provide an easy-to-use mechanism for all common types of standard validation—for example, testing for valid dates or values within a range—plus ways to provide custom-written validation. In addition, validation controls allow you to customize how error information is displayed to the user.

Validation controls can be used with any controls you put on an ASP.NET Web page, including both HTML and Web server controls.

Security Note

By default, ASP.NET Web pages automatically check for potentially malicious input.

You enable validation of user input by adding validation controls to your page as you would add other server controls. There are controls for different types of validation, such as range checking or pattern matching. Each validation control references an input control (a server control) elsewhere on the page. When user input is being processed (for example, when a page is submitted), the validation control tests the user input and sets a property to indicate whether the entry passed the test. After all of the validation controls have been called, a property on the page is set indicating whether any validation check has failed.

Validation controls can be associated into validation groups so that validation controls belonging to a common group are validated together. You can use validation groups to selectively enable or disable validation for related controls on a page. Other validation operations, such as displaying a ValidationSummary control or calling the GetValidators method, can reference the validation group.

You can test the state of the page and of individual controls in your own code. For example, you would test the state of the validation controls before updating a data record with information entered by the user. If you detect an invalid state, you bypass the update. Typically, if any validation checks fail, you skip all of your own processing and return the page to the user. Validation controls that detect errors then produce an error message that appears on the page. You can display all validation errors in one place using a ValidationSummary control.

Note

Data-bound controls that update, insert, and delete data, such as the GridView, FormView, and DetailsView controls, automatically verify that validation checks have passed before performing a data update operation.

When Validation Occurs

Validation controls perform input checking in server code. When the user submits a page to the server, the validation controls are invoked to check the user input, control by control. If a validation error is detected in any of the input controls, the page itself is set to an invalid state so you can test for validity before your code runs. Validation occurs after page initialization (that is, after view state and postback data have been processed) but before any change or click event handlers are called.

If the user is working with a browser that supports ECMAScript (Javascript), the validation controls can also perform validation using client script. This can improve response time in the page because errors are detected immediately and error messages are displayed as soon as the user leaves the control containing the error. If client-side validation is available, you have greater control over the layout of error messages and can display an error summary in a message box.

ASP.NET performs validation on the server even if the validation controls have already performed it on the client, so that you can test for validity within your server-based event handlers. In addition, re-testing on the server helps prevent users from being able to bypass validation by disabling or changing the client script check.

You can invoke validation in your own code by calling a validation control's Validate method.

Validating for Multiple Conditions

Each validation control typically performs one test. However, you might want to check for multiple conditions. For example, you might want to specify both that a user entry is required and that the user entry is limited to accepting dates within a specific range.

You can attach more than one validation control to an input control on a page. In that case, the tests performed by the controls are resolved using a logical AND operator, which means that the data entered by the user must pass all of the tests in order to be considered valid.

In some instances, entries in several different formats might be valid. For example, if you are prompting for a phone number, you might allow users to enter a local number, a long-distance number, or an international number. Using multiple validation controls would not work in this instance because the user input must pass all tests to be valid. To perform this type of test—a logical OR operation where only one test must pass—use the RegularExpressionValidator validation control and specify multiple valid patterns within the control. Alternatively, you can use the CustomValidator validation control and write your own validation code.

Displaying Error Information

Validation controls are not normally visible in the rendered page. However, if the control detects an error, it displays the error message text that you specify. The error message can be displayed in a variety of ways, as listed in the following table.

Display method	Description
Inline	Each validation control can individually display an error message in place (usually next to the control where the error occurred).
Summary	Validation errors can be collected and displayed in one place—for example, at the top of the page. This strategy is often used in combination with displaying a message next to the input fields with errors. If the user is working in Internet Explorer 4.0 or later, the summary can be displayed in a message box. If you are using validation groups, you need a ValidationSummary control for each separate group.
In place and summary	The error message can be different in the summary and in place. You can use this option to show a shorter error message in place with more detail in the summary.
Custom	You can customize the error message display by capturing the error information and designing your own output.

If you use the in-place or summary display options, you can format the error message text using HTML.

Security Note

If you create custom error messages, make sure that you do not display information that might help a malicious user compromise your application.

You can interact with validation controls by using the object model that is exposed by individual validation controls and by the page. Each validation control exposes its own IsValid property that you can test to determine whether a validation test has passed or failed for that control. The page also exposes an IsValid property that summarizes the IsValid state of all the validation controls on the page. This property allows you to perform a single test to determine whether you can proceed with your own processing.

The page also exposes a Validators collection containing a list of all the validation controls on the page. You can loop through this collection to examine the state of individual validation controls.

Customizing Validation

You can customize the validation process in the following ways:

• You can specify the format, text, and location of error messages. In addition, you can specify whether the error messages appear individually or as a summary.
• You can create custom validation using CustomValidator control. The control calls your logic but otherwise functions like other validation controls in setting error state, displaying error messages, and so on. This provides an easy way to create custom validation logic while still using in the validation framework of the page.
• For client-side validation, you can intercept the validation call and substitute or add your own validation logic.

Client-Side Validation for ASP.NET Server Controls 

If the user is working with a browser that supports dynamic HTML (DHTML), ASP.NET validation controls can perform validation using client script. Because the controls can provide immediate feedback without a round trip to the server, the user experience with the page is enhanced.

Under most circumstances, you do not have to make any changes to your page or to the validation controls to use client-side validation. The controls automatically detect if the browser supports DHTML and perform their checking accordingly. Client-side validation uses the same error display mechanism as server-side validation.

Security Note

Validation is performed on the server even if it was already performed on the client. This enables you to determine validation status in server code and provides security against users bypassing client-side validation.

Differences in Client-Side Validation

If validation is performed on the client, validation controls include some additional features:

• If you are summarizing validation error messages, you can display them in a message box that appears when the user submits the page. For details, see How to: Control Validation Error Message Display for ASP.NET Server Controls.
• The object model for validation controls is slightly different on the client. See Client Validation Object Model later in this topic.

There are a few minor differences associated with client-side validation:

• If client-side validation is enabled, the page includes references to script libraries that are used to perform the client-side validation.
• When you use a RegularExpressionValidator control, the expressions can be checked on the client if an ECMAScript-compatible language (such as Microsoft JScript) is available. Client-side regular expressions differ in small details from the regular expression checking done on the server using the Regex class.
• The page includes a client-side method to intercept and handle the Click event before the page is submitted.

Client Validation Object Model

Validation controls present almost the same object model on the client as on the server. For example, you can test validation by reading a validation control's IsValid property the same way on both the client and the server.

However, there are differences in the validation information exposed at the page level. On the server, the page supports properties; on the client, it contains global variables. The following table compares the information exposed on the page.

Client Page Variable	Server Page Property
Page_IsValid	IsValid
Page_Validators (array)   Contains references to all validation controls on the page.	Validators (collection)   Contains references to all validation controls.
Page_ValidationActive   A Boolean value that indicates whether validation should take place. Set this variable to false to turn off client-side validation programmatically.	(no equivalent)
Note All page-related validation information should be considered read-only.

Posting Pages with Client-Side Validation Errors

In some instances, you might prefer not to use client-side validation and to use only server-side validation, even if client-side validation is available. For example, client-side validation might not be possible if validation requires information or resources that are available only on the server, such as access to a database.

By default, when client-side validation is being performed, the user cannot post the page to the server if there are errors on the page. However, you might find it necessary to enable the user to post even with errors. For example, you might have a cancel button or a navigation button on a page, and you want the button to submit the page even if some controls would fail validation.

How to: Disable Validation for ASP.NET Server Controls 

You might want to bypass validation under certain circumstances. For example, you might have a page in which users should be able to post even if they did not fill out all the validated fields correctly. You can set an ASP.NET server control to bypass validation on both the server and the client, or just on the client.

Security Note

By default, ASP.NET Web pages perform request validation to ensure that user input does not include script or HTML elements. You can disable this feature explicitly

You can also disable a validation control so that it is not rendered to the page at all and no validation takes place using that control.

If you want to perform validation on the server but not on the client, you can set an individual validation control to not emit client-side script. This is useful if dynamic updating on the client creates problems with the layout of the page, or if you want to execute some server code before validation takes place.

To disable validation in a specific control

• Set the control's CausesValidation property to false.

The following example shows how you can create a Cancel button that bypasses a validation check:

Visual Basic

<asp:Button id="Button1" runat="server"

  Text="Cancel" CausesValidation="False">

</asp:Button>

C#

<asp:Button id="Button1" runat="server"

  Text="Cancel" CausesValidation="False">

</asp:Button>

To disable a validation control

• Set the validation control's Enabled property to false.

To disable client-side validation

• Set the validation control's EnableClientScript property to false.

Asp.net Validation controls 

RequiredFieldValidator

The RequiredFieldValidator control ensures that the user does not skip an entry. The control fails validation if the value it contains does not change from its initial value when validation is performed. If all the fields in the page are valid, the page is valid.

RangeValidator

The RangeValidator control tests whether an input value falls within a given range. RangeValidator uses three key properties to perform its validation: ControlToValidate contains the value to validate, MinimumValue defines the minimum value of the valid range, and MaximumValue defines the maximum value of the valid range. These constants are stored as string values, but are converted to the data type defined by Type when the comparison is performed.

RegularExpressionValidator

The RegularExpressionValidator control confirms that the entry matches a pattern defined by a regular expression. This type of validation allows you to check for predictable sequences of characters, such as those in social security numbers, e-mail addresses, telephone numbers, postal codes, and so on.

RegularExpressionValidator uses two key properties to perform its validation: ControlToValidate contains the value to validate, and ValidationExpression contains the regular expression to match.

CustomValidator

The CustomValidator control calls a user-defined function to perform validations that the standard validators can't handle. The custom function can execute on the server or in client-side script, such as JScript or VBScript. For client-side custom validation, the name of the custom function must be identified in the ClientValidationFunction property. The custom function must have the form function myvalidator(source, arguments) Note that source is the client-side CustomValidator object, and arguments is an object with two properties, Value and IsValid. The Value property is the value to be validated and the IsValid property is a Boolean used to set the return result of the validation.
For server-side custom validation, place your custom validation in the validator's OnServerValidate delegate.

ValidationSummary

When the user's input is processed (for example, when the form is submitted), the Web Forms framework passes the user's entry to the associated validation control or controls. The validation controls test the user's input and set a property to indicate whether the entry passed the validation test. After all validation controls have been processed, the IsValid property on the page is set; if any of the controls shows that a validation check failed, the entire page is set to invalid.

A ValidationSummary control is displayed when the IsValid property of the page is false. It "polls" each of the validation controls on the page and aggregates the text messages exposed by each. The following sample illustrates displaying errors with a ValidationSummary.

Share this

Suresh Pydi