ASP.NET Page Life Cycle
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.
General Page Life-cycle Stages
In general terms, the page goes through the
stages outlined in the following table.
Stage
|
Description
|
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.
PreInit
|
Use
this event for the following:
a) Check the IsPostBack property to determine whether this is the first
time the page is being processed.
b) Create or re-create dynamic controls.
c) Set a master page dynamically.
d) Set the Theme property dynamically.
e) 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. Before the Page instance 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.
Note:
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:
a) The Page object calls EnsureChildControls for each control and for
the page.
b) Each data bound control whose DataSourceID property is set calls its
DataBind method.
|
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, you must explicitly
call the base method. For example, if you override the OnLoad method on the
page, you must call base.Load 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.
|
RowCreated
(GridView only) or ItemCreated(DataList, DetailsView, SiteMapPath, DataGrid,
FormView, Repeater, and ListView 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, Repeater,
and ListView 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.
|
Login Control Events
The Login control can use settings in the
Web.config file to manage membership authentication automatically. However, if
your application requires you to customize how the control works, or if you
want to understand how Login control events relate to the page life cycle, you
can use the events listed in the following table.
Control
Event
|
Typical
Use
|
LoggingIn
|
This
event is raised during a postback, after the page's LoadComplete event has
occurred. It marks the beginning of the login process. Use this event for
tasks that must occur prior to beginning the authentication process.
|
Authenticate
|
This
event is raised after the LoggingIn event. Use this event to override or
enhance the default authentication behavior of a Login control.
|
LoggedIn
|
This
event is raised after the user name and password have been authenticated. Use
this event to redirect to another page or to dynamically set the text in the
control. This event does not occur if there is an error or if authentication
fails.
|
LoginError
|
This
event is raised if authentication was not successful. Use this event to set
text in the control that explains the problem or to direct the user to a
different page.
|
0 comments:
Post a Comment