6.3 Lifecycle
A user sits at her browser and types in a URL. A
web
page appears, with text and images and buttons and so forth. She
fills in a text box and clicks on a button. What is going on behind
the scenes?
Every request made of the web server initiates a sequence of
steps. These steps, from beginning to end,
constitute the lifecycle of the page.
When a page is requested, it is loaded, processed, sent to the user,
and unloaded. From one end of the lifecycle to the
other, the goal of the page is to render appropriate HTML and other
output back to the requesting browser. At each
step, there are methods and events available to let you override the
default behavior or add your own programmatic enhancements.
To fully understand the lifecycle of the page and its controls, it is
necessary to recognize that the
Page class creates a hierarchical tree
of all the controls on the page. All the components on the page,
except for any Page directives (described
shortly), are part of this control
tree.
You can see the control tree for any
page by adding trace="true" to the
Page directive.
(Page directives are described in the next section
of this chapter. Chapter 7 discusses tracing in
detail.)
The Page itself is at the root of the tree. All
the named controls are included in the tree, referenced by control
ID. Static text, including whitespace, NewLines,
and HTML tags, are represented in the tree as
LiteralControls. The
order of controls in the tree is strictly
hierarchical. Within a given hierarchy level, the
controls are ordered in the tree using the same sequence in which
they appear in the page file.
Web components, including the Page, go through the entire lifecycle
every time the page is loaded. (This involves a
fair amount of
performance overhead, which you can reduce
by caching; this is covered in Chapter 18.) Events
fire first on the Page, then recursively on every object in the
control tree.
The following is a detailed description of each of the phases of the
component lifecycle in a web form. There are two slightly different
sequences of events in the lifecycle: on the first loading of the
page and on subsequent postbacks. This lifecycle is shown
schematically in Figure 6-5.
During the first page load, the lifecycle is composed of the
following steps:
Initialization The
initialization
phase is the first phase in the
lifecycle for any page or control. The control tree is built during
the initialization phase. In this phase, you can
initialize any values needed for the duration of the request. The initialize phase is modified by handling the
Init event with the
OnInit method. Load User code runs and the form controls show client-side data. The load phase can be modified by handling the Load event with the
OnLoad method. PreRender This is the phase just before the output is rendered.
CreateChildControls is called, if necessary, to create and initialize
server controls in the control tree. Modifications are made via the
PreRender
event, using the OnPreRender method. Save ViewState The
view state is saved to a hidden
variable on the page, persisting as a string object that will
complete the round trip to the client. This can be overridden using
the
SaveViewState method. Render The page and its controls are rendered as HTML.
You can override using the
Render method.
Within Render, CreateChildControls is called, if necessary, to create
and initialize server controls in the control tree. Dispose This is the last phase of the lifecycle. It gives
you an opportunity to do any final cleanup and release references to
any expensive resources, such as database
connections. This is important for
scalability. It can be modified using the
Dispose method.
During
postback,
the lifecycle is:
Initialization Same as on first load. Load ViewState The
ViewState property of the control is
loaded from a hidden variable on the page, as described in
"View State"
earlier in this chapter. You can modify this behavior by overriding
the
LoadViewState
method. Postback Data is loaded During this phase, the data sent to the server via the POST method is
processed. Any updates to the view state necessitated by the postback
are performed via the
LoadPostData
method. Load Same as on first load. Change events are raised If there are any state changes between the current state and the
previous state, change events are raised via the
RaisePostDataChangedEvent
method. Again, the events are raised for the
controls in the order in which the controls appear in the control
tree. Handle postback events Exactly one user action caused the postback. That
user action is handled now, after all the change events have been
handled. The original client-side event that
instigated the postback is handled in the
RaisePostBackEvent
method. PreRender Same as on first load. Save ViewState Same as on first load. Render Same as on first load. Dispose Same as on first load.
|