Page and control lifecycle

J

John Lau

Hi,

Is there documentation that talks about the page lifecycle, the lifecycle of
controls on the page, and the rendering of inline code, in a single
document?

Thanks,
John
 
S

Scott Mitchell [MVP]

John said:
Is there documentation that talks about the page lifecycle, the lifecycle of
controls on the page, and the rendering of inline code, in a single
document?

John, you might want to check out the following article by Dino Esposito:

The ASP.NET Page Object Model
http://msdn.microsoft.com/library/en-us/dnaspp/html/aspnet-pageobjectmodel.asp

Also, here is a snippet from an upcoming article of mine on ASP.NET View
State, which will be appearing on the MSDN Dev Center
[http://msdn.microsoft.com/asp.net/] sometime within the next few weeks,
hopefully. (You'll have to wait to see the referred screenshots, or you
can email me [[email protected]] and I'll be happy to send you
a draft form of this article...)

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

The ASP.NET Page Life Cycle
Each time a request arrives at a Web server for an ASP.NET Web page, the
first thing the Web server does is hand off the request to the ASP.NET
engine. The ASP.NET engine, then, takes the request through a pipeline
composed of numerous stages that includes verifying file access rights
for the ASP.NET Web page, resurrecting the user’s session state, and so
on. At the end of the pipeline, a class corresponding to the requested
ASP.NET Web page is instantiated and its ProcessRequest() method is
invoked (see Figure 1).

INSERT FIGURE01.BMP HERE, PLEASE

This ASP.NET page life cycle starts with a call to the ProcessRequest()
method. This method begins by initializing the page’s control
hierarchy. Next, the page and its server controls proceed lock-step
through various phases that are essential to executing an ASP.NET Web
page. These steps include managing view state, handling postback
events, and rendering the page’s HTML markup. Figure 2 provides a
graphical representation of the ASP.NET page life cycle. The life cycle
ends by handing off the Web page’s HTML markup to the Web server, which
sends it back to the client that requested the page.

Note: A detailed discussion of the steps leading up to the ASP.NET page
life cycle is beyond the scope of this article. For more information
read Michele Leroux-Bustamante’s Inside IIS & ASP.NET. For a more
detailed look at HTTP handlers, which are the endpoints of the ASP.NET
pipeline, check out INSERT LINK/URL TO MY HTTP HANDLERS ARTICLE HERE,
PLEASE.

What is important to realize is that each and every time an ASP.NET Web
page is requested it goes through these same life cycle stages (shown in
Figure 2).

INSERT FIGURE02.BMP HERE, PLEASE

Stage 0 – Instantiation
The ASP.NET page life cycle begins with instantiation of the class that
represents the requested ASP.NET Web page. But how is this class
created? Where is it stored?

ASP.NET Web pages, as you know, are made up of both an HTML portion and
a code portion, with the HTML portion containing HTML markup and Web
control syntax. The ASP.NET engine converts the HTML portion from its
free-form text representation into a series of programmatically-created
Web controls.

When an ASP.NET Web page is visited for the first time after a change
has been made to the HTML markup or Web control syntax in the .aspx
page, the ASP.NET engine autogenerates a class. If you created your
ASP.NET Web page using the code-behind technique, this autogenerated
class is derived from the page’s associated code-behind class (note that
the code-behind class must be derived itself, either directly or
indirectly, from the System.Web.UI.Page class); if you created your page
with an in-line, server-side <script> block, the class derives directly
from System.Web.UI.Page. In either case, this autogenerated class,
along with a compiled instance of the class, is stored in the
WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder,
in part so that it doesn’t need to be recreated for each page request.

The purpose of this autogenerated class is to programmatically create
the page’s control hierarchy. That is, the class is responsible for
programmatically creating the Web controls specified in the page’s HTML
portion. This is done by translating the Web control syntax -
<asp:WebControlName Prop1=”Value1” ... /> - into the class’s programming
language (C# or VB.NET, most typically). In addition to the Web control
syntax being converted into the appropriate code, the HTML markup
present in the ASP.NET Web page’s HTML portion is translated to Literal
controls.

All ASP.NET server controls can have a parent control, along with a
variable number of child controls. The System.Web.UI.Page class is
derived from the base control class (System.Web.UI.Control) and
therefore also can have a set of child controls. The top-level controls
declared in an ASP.NET Web page’s HTML portion are the direct children
of the autogenerated Page class. Web controls can also be nested inside
one another. For example, most ASP.NET Web pages contain a single
server-side Web Form with multiple Web controls inside the Web Form.
The Web Form is an HTML control (System.Web.UI.HtmlControls.HtmlForm).
Those Web controls inside the Web Form are children of the Web Form.

Since server controls can have children, and each of their children may
have children, and so on, a control and its descendents form a tree of
controls. This tree of controls is called the control hierarchy. The
root of the control hierarchy for an ASP.NET Web page is the
Page-derived class autogenerated by the ASP.NET engine.

Whew! Those last few paragraphs may have been a bit confusing, as this
is not the easiest subject to discuss or digest. To clear out any
potential confusion, let’s look at a quick example. Imagine you have an
ASP.NET Web page with the following HTML portion:

<html>
<body>
<h1>Welcome to my Homepage!</h1>
<form runat="server">
What is your name?
<asp:TextBox runat="server" ID="txtName"></asp:TextBox>
<br />What is your gender?
<asp:DropDownList runat="server" ID="ddlGender”>
<asp:ListItem Select="True" Value="M">Male</asp:ListItem>
<asp:ListItem Value="F">Female</asp:ListItem>
<asp:ListItem Value="U">Undecided</asp:ListItem>
</asp:DropDownList>
<br />
<asp:Button runat="server" Text="Submit!"></asp:Button>
</form>
</body>
</html>

When this page is first visited, a class will be autogenerated
containing code to programmatically build up the control hierarchy. The
control hierarchy for this example can be seen in Figure 3. The code
that the above HTML portion gets translated to is shown after Figure 3.

INSERT FIGURE03.BMP HERE, PLEASE

Page.Controls.Add(new LiteralControl("<html>\r\n<body>\r\n<h1>Welcome to
my Homepage!</h1>\r\n"));

HtmlForm Form1 = new HtmlForm();
Form1.ID = "Form1";
Form1.Method = "post";

Form1.Controls.Add(new LiteralControl("\r\nWhat is your name?\r\n"));

TextBox TextBox1 = new TextBox();
TextBox1.ID = "txtName";
Form1.Controls.Add(TextBox1);

Form1.Controls.Add(new LiteralControl("\r\n<br />What is your
gender?\r\n"));

DropDownList DropDownList1 = new DropDownList();
DropDownList1.ID = "ddlGender";

ListItem ListItem1 = new ListItem();
ListItem1.Selected = true;
ListItem1.Value = "M";
ListItem1.Text = "Male";
DropDownList1.Items.Add(ListItem1);

ListItem ListItem2 = new ListItem();
ListItem2.Value = "F";
ListItem2.Text = "Female";
DropDownList1.Items.Add(ListItem2);

ListItem ListItem3 = new ListItem();
ListItem3.Value = "U";
ListItem3.Text = "Undecided";
DropDownList1.Items.Add(ListItem3);

Form1.Controls.Add(new LiteralControl("\r\n<br /> \r\n"));

Button Button1 = new Button();
Button1.Text = "Submit!";
Form1.Controls.Add(Button1);

Form1.Controls.Add(new LiteralControl("\r\n</body>\r\n</html>"));

Controls.Add(Form1);

Note: The C# source code above is not the precise code autogenerated by
the ASP.NET engine. Rather, it’s a cleaner and easier to read version
of the autogenerated code. To see the full autogenerated code – which
won’t win any points for readability - navigate to the
WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder
and open one of the .cs or .vb files.

One thing to notice is that when the control hierarchy is constructed
the properties explicitly set in the Web control’s declarative syntax
are assigned in the code. (For example, the Button Web control has its
Text property set to “Submit!” in the declarative syntax –
Text="Submit!" – as well as in the autogenerated class – Button1.Text =
"Submit!";.

Stage 1 – Initialization
After the control hierarchy has been built, the Page, along with all of
the controls in its control hierarchy, enter the initialization stage.
This stage is marked by having the Page and controls fire their Init
events. At this point in the page life cycle, the control hierarchy has
been constructed and the Web control properties specified in the
declarative syntax have been assigned.

We’ll look at the initialization stage in more detail later in this
article. With regards to view state it is important for two reasons.
First, server controls don’t begin tracking view state changes until
right at the end of the initialization stage. Second, when adding
dynamic controls that need to utilize view state, these controls will
need to be added during the Page’s Init event as opposed to the Load
event, as we’ll see shortly.

Stage 2 – Load View State
The load view state stage only happens when the page has been posted
back. During this stage the view state data saved from the previous
page visit is loaded and recursively populated into the Page’s control
hierarchy. It is during this stage that the view state is validated.
As we’ll discuss later on in this article, the view state can become
invalid due to a number of reasons, such as view state tampering and
injecting dynamic controls into the middle of the control hierarchy.

Stage 3 – Load Postback Data
The load postback data stage also only happens when the page has been
posted back. A server control can indicate that it is interested in
examining the posted back data by implementing the IPostBackDataHandler
interface. In this stage in the page life cycle, the Page class
enumerates the posted back form fields, and searches for the
corresponding server control. If it finds the control, it checks to see
if the control implements the IPostBackDataHandler interface. If it
does, it hands off the appropriate postback data to the server control
by calling the control’s LoadPostData() method. The server control
would then update its state based on this postback data.

To help clarify things, let’s look at a simple example. One nice thing
about ASP.NET is that the Web controls in a Web Form remember their
values across postback. That is, if you have a TextBox Web control on a
page and the user enters some value into the TextBox and posts back the
page, the TextBox’s Text property is automatically updated to the user’s
entered value. This happens because the TextBox Web control implements
the IPostBackDataHandler interface, and the Page class hands off the
appropriate value to the TextBox class, which then updates its Text
property.

To concretize things, imagine that we have an ASP.NET Web page with a
TextBox whose ID property is set to txtName. When the page is first
visited, the following HTML will be rendered for the TextBox: <input
type="text" id="txtName" name="txtName" />. When the user enters a
value into this TextBox (such as, “Hello, World!”) and submits the form,
their browser will make a request to the same ASP.NET Web page, passing
back in the HTTP POST headers the form field values. These include the
hidden form field values (such as __VIEWSTATE), along with the value
from the txtName TextBox.

When the ASP.NET Web page is posted back, in the load postback data
stage the Page class sees that one of the posted back form fields
corresponds IPostBackDataHandler interface. There is such a control in
the hierarchy, so the TextBox’s LoadPostData() method is invoked,
passing in the value the user entered into the TextBox (“Hello,
World!”). The TextBox’s LoadPostData() method simply assigns this
passed in value to its Text property.

Notice that in our discussion on the load postback data stage, there was
no mention of view state. Therefore, you might naturally be wondering
why I bothered to mention the load postback data stage in an article
about view state. The reason is to note the absence of view state in
this stage. It is a common misconception among developers that view
state is somehow responsible for having TextBoxes, CheckBoxes,
DropDownLists, and other Web controls remember their values across
postback. This is not the case, as the values are identified via posted
back form field values, and assigned in the LoadPostData() method for
those controls that implement IPostBackDataHandler.

Stage 4 – Load
This is the stage all ASP.NET developers are familiar with, as we’ve all
created an event handler for a page’s Load event (Page_Load). When the
Load event fires, the view state has been loaded (from stage 2, Load
View State) along with the postback data (from stage 3, Load Postback
Data). If the page has been posted back, when the Load event fires we
know that the page has been restored to its state from the previous page
visit.

Stage 5 – Raise Postback Event
Certain server controls raise events with respect to changes that
occurred between postbacks. For example, the DropDownList Web control
has a SelectedIndexChanged event that fires if the DropDownList’s
SelectedIndex has changed from the SelectedIndex value in the previous
page load. Another example: if the Web Form was posted back due to a
Button Web control being clicked, the Button’s Click event is fired
during this stage.

There are two flavors of postback events. The first is a changed event.
This event fires when some piece of data is changed between postbacks.
An example is the DropDownLists SelectedIndexChanged event, or the
TextBox’s TextChanged event. Server controls that provide changed
events must implement the IPostBackDataHandler interface. The other
flavor of postback events are raised events. These are events that are
raised by the server control for whatever reason the control sees fit.
For example, the Button Web control raises the Click event when it is
clicked; the Calendar control raises the VisibleMonthChanged event when
the user moves to another month. Controls that fire raised events must
implement the IPostBackEventHandler interface.

Since this stage inspects postback data to determine if any events need
to be raised, the stage only occurs when the page has been posted back.
As with the load postback data stage, the raise postback event stage
does not use view state information at all. Whether or not an event is
raised depends on the data posted back in the form fields.

Stage 6 – Save View State
In the save view state stage, the Page class constructs the page’s view
state, which represents the state that must persist across postbacks.
The page accomplishes this by recursively calling the SaveViewState()
method of the controls in its control hierarchy. This combined, saved
state is then serialized into a base-64 encoded string. In stage 7,
when the page’s Web Form is rendered, the view state is persisted in the
page as a hidden form field.

Stage 7 – Render
In the render stage the HTML that is emitted to the client requesting
the page is generated. The Page class accomplishes this by recursively
invoking the RenderControl() method of each of the controls in its
hierarchy.

These seven stages are the most important stages with respect to
understanding view state. (Note that I did omit a couple of stages,
such as the PreRender and Unload stages.) As you continue through the
article, keep in mind that every single time an ASP.NET Web page is
requested, it proceeds through these series of stages.



--

Scott Mitchell
(e-mail address removed)
http://www.4GuysFromRolla.com
http://www.ASPFAQs.com
http://www.ASPMessageboard.com

* When you think ASP, think 4GuysFromRolla.com!
 
J

John Lau

Hey Scott,

The temp folder and articles help a lot. Thanks for the quick response.

John

Scott Mitchell said:
John said:
Is there documentation that talks about the page lifecycle, the lifecycle of
controls on the page, and the rendering of inline code, in a single
document?

John, you might want to check out the following article by Dino Esposito:

The ASP.NET Page Object Model
http://msdn.microsoft.com/library/en-us/dnaspp/html/aspnet-pageobjectmodel.asp

Also, here is a snippet from an upcoming article of mine on ASP.NET View
State, which will be appearing on the MSDN Dev Center
[http://msdn.microsoft.com/asp.net/] sometime within the next few weeks,
hopefully. (You'll have to wait to see the referred screenshots, or you
can email me [[email protected]] and I'll be happy to send you
a draft form of this article...)

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

The ASP.NET Page Life Cycle
Each time a request arrives at a Web server for an ASP.NET Web page, the
first thing the Web server does is hand off the request to the ASP.NET
engine. The ASP.NET engine, then, takes the request through a pipeline
composed of numerous stages that includes verifying file access rights
for the ASP.NET Web page, resurrecting the user’s session state, and so
on. At the end of the pipeline, a class corresponding to the requested
ASP.NET Web page is instantiated and its ProcessRequest() method is
invoked (see Figure 1).

INSERT FIGURE01.BMP HERE, PLEASE

This ASP.NET page life cycle starts with a call to the ProcessRequest()
method. This method begins by initializing the page’s control
hierarchy. Next, the page and its server controls proceed lock-step
through various phases that are essential to executing an ASP.NET Web
page. These steps include managing view state, handling postback
events, and rendering the page’s HTML markup. Figure 2 provides a
graphical representation of the ASP.NET page life cycle. The life cycle
ends by handing off the Web page’s HTML markup to the Web server, which
sends it back to the client that requested the page.

Note: A detailed discussion of the steps leading up to the ASP.NET page
life cycle is beyond the scope of this article. For more information
read Michele Leroux-Bustamante’s Inside IIS & ASP.NET. For a more
detailed look at HTTP handlers, which are the endpoints of the ASP.NET
pipeline, check out INSERT LINK/URL TO MY HTTP HANDLERS ARTICLE HERE,
PLEASE.

What is important to realize is that each and every time an ASP.NET Web
page is requested it goes through these same life cycle stages (shown in
Figure 2).

INSERT FIGURE02.BMP HERE, PLEASE

Stage 0 – Instantiation
The ASP.NET page life cycle begins with instantiation of the class that
represents the requested ASP.NET Web page. But how is this class
created? Where is it stored?

ASP.NET Web pages, as you know, are made up of both an HTML portion and
a code portion, with the HTML portion containing HTML markup and Web
control syntax. The ASP.NET engine converts the HTML portion from its
free-form text representation into a series of programmatically-created
Web controls.

When an ASP.NET Web page is visited for the first time after a change
has been made to the HTML markup or Web control syntax in the .aspx
page, the ASP.NET engine autogenerates a class. If you created your
ASP.NET Web page using the code-behind technique, this autogenerated
class is derived from the page’s associated code-behind class (note that
the code-behind class must be derived itself, either directly or
indirectly, from the System.Web.UI.Page class); if you created your page
with an in-line, server-side <script> block, the class derives directly
from System.Web.UI.Page. In either case, this autogenerated class,
along with a compiled instance of the class, is stored in the
WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder,
in part so that it doesn’t need to be recreated for each page request.

The purpose of this autogenerated class is to programmatically create
the page’s control hierarchy. That is, the class is responsible for
programmatically creating the Web controls specified in the page’s HTML
portion. This is done by translating the Web control syntax -
<asp:WebControlName Prop1=”Value1” ... /> - into the class’s programming
language (C# or VB.NET, most typically). In addition to the Web control
syntax being converted into the appropriate code, the HTML markup
present in the ASP.NET Web page’s HTML portion is translated to Literal
controls.

All ASP.NET server controls can have a parent control, along with a
variable number of child controls. The System.Web.UI.Page class is
derived from the base control class (System.Web.UI.Control) and
therefore also can have a set of child controls. The top-level controls
declared in an ASP.NET Web page’s HTML portion are the direct children
of the autogenerated Page class. Web controls can also be nested inside
one another. For example, most ASP.NET Web pages contain a single
server-side Web Form with multiple Web controls inside the Web Form.
The Web Form is an HTML control (System.Web.UI.HtmlControls.HtmlForm).
Those Web controls inside the Web Form are children of the Web Form.

Since server controls can have children, and each of their children may
have children, and so on, a control and its descendents form a tree of
controls. This tree of controls is called the control hierarchy. The
root of the control hierarchy for an ASP.NET Web page is the
Page-derived class autogenerated by the ASP.NET engine.

Whew! Those last few paragraphs may have been a bit confusing, as this
is not the easiest subject to discuss or digest. To clear out any
potential confusion, let’s look at a quick example. Imagine you have an
ASP.NET Web page with the following HTML portion:

<html>
<body>
<h1>Welcome to my Homepage!</h1>
<form runat="server">
What is your name?
<asp:TextBox runat="server" ID="txtName"></asp:TextBox>
<br />What is your gender?
<asp:DropDownList runat="server" ID="ddlGender”>
<asp:ListItem Select="True" Value="M">Male</asp:ListItem>
<asp:ListItem Value="F">Female</asp:ListItem>
<asp:ListItem Value="U">Undecided</asp:ListItem>
</asp:DropDownList>
<br />
<asp:Button runat="server" Text="Submit!"></asp:Button>
</form>
</body>
</html>

When this page is first visited, a class will be autogenerated
containing code to programmatically build up the control hierarchy. The
control hierarchy for this example can be seen in Figure 3. The code
that the above HTML portion gets translated to is shown after Figure 3.

INSERT FIGURE03.BMP HERE, PLEASE

Page.Controls.Add(new LiteralControl("<html>\r\n<body>\r\n<h1>Welcome to
my Homepage!</h1>\r\n"));

HtmlForm Form1 = new HtmlForm();
Form1.ID = "Form1";
Form1.Method = "post";

Form1.Controls.Add(new LiteralControl("\r\nWhat is your name?\r\n"));

TextBox TextBox1 = new TextBox();
TextBox1.ID = "txtName";
Form1.Controls.Add(TextBox1);

Form1.Controls.Add(new LiteralControl("\r\n<br />What is your
gender?\r\n"));

DropDownList DropDownList1 = new DropDownList();
DropDownList1.ID = "ddlGender";

ListItem ListItem1 = new ListItem();
ListItem1.Selected = true;
ListItem1.Value = "M";
ListItem1.Text = "Male";
DropDownList1.Items.Add(ListItem1);

ListItem ListItem2 = new ListItem();
ListItem2.Value = "F";
ListItem2.Text = "Female";
DropDownList1.Items.Add(ListItem2);

ListItem ListItem3 = new ListItem();
ListItem3.Value = "U";
ListItem3.Text = "Undecided";
DropDownList1.Items.Add(ListItem3);

Form1.Controls.Add(new LiteralControl("\r\n<br /> \r\n"));

Button Button1 = new Button();
Button1.Text = "Submit!";
Form1.Controls.Add(Button1);

Form1.Controls.Add(new LiteralControl("\r\n</body>\r\n</html>"));

Controls.Add(Form1);

Note: The C# source code above is not the precise code autogenerated by
the ASP.NET engine. Rather, it’s a cleaner and easier to read version
of the autogenerated code. To see the full autogenerated code – which
won’t win any points for readability - navigate to the
WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder
and open one of the .cs or .vb files.

One thing to notice is that when the control hierarchy is constructed
the properties explicitly set in the Web control’s declarative syntax
are assigned in the code. (For example, the Button Web control has its
Text property set to “Submit!” in the declarative syntax –
Text="Submit!" – as well as in the autogenerated class – Button1.Text =
"Submit!";.

Stage 1 – Initialization
After the control hierarchy has been built, the Page, along with all of
the controls in its control hierarchy, enter the initialization stage.
This stage is marked by having the Page and controls fire their Init
events. At this point in the page life cycle, the control hierarchy has
been constructed and the Web control properties specified in the
declarative syntax have been assigned.

We’ll look at the initialization stage in more detail later in this
article. With regards to view state it is important for two reasons.
First, server controls don’t begin tracking view state changes until
right at the end of the initialization stage. Second, when adding
dynamic controls that need to utilize view state, these controls will
need to be added during the Page’s Init event as opposed to the Load
event, as we’ll see shortly.

Stage 2 – Load View State
The load view state stage only happens when the page has been posted
back. During this stage the view state data saved from the previous
page visit is loaded and recursively populated into the Page’s control
hierarchy. It is during this stage that the view state is validated.
As we’ll discuss later on in this article, the view state can become
invalid due to a number of reasons, such as view state tampering and
injecting dynamic controls into the middle of the control hierarchy.

Stage 3 – Load Postback Data
The load postback data stage also only happens when the page has been
posted back. A server control can indicate that it is interested in
examining the posted back data by implementing the IPostBackDataHandler
interface. In this stage in the page life cycle, the Page class
enumerates the posted back form fields, and searches for the
corresponding server control. If it finds the control, it checks to see
if the control implements the IPostBackDataHandler interface. If it
does, it hands off the appropriate postback data to the server control
by calling the control’s LoadPostData() method. The server control
would then update its state based on this postback data.

To help clarify things, let’s look at a simple example. One nice thing
about ASP.NET is that the Web controls in a Web Form remember their
values across postback. That is, if you have a TextBox Web control on a
page and the user enters some value into the TextBox and posts back the
page, the TextBox’s Text property is automatically updated to the user’s
entered value. This happens because the TextBox Web control implements
the IPostBackDataHandler interface, and the Page class hands off the
appropriate value to the TextBox class, which then updates its Text
property.

To concretize things, imagine that we have an ASP.NET Web page with a
TextBox whose ID property is set to txtName. When the page is first
visited, the following HTML will be rendered for the TextBox: <input
type="text" id="txtName" name="txtName" />. When the user enters a
value into this TextBox (such as, “Hello, World!”) and submits the form,
their browser will make a request to the same ASP.NET Web page, passing
back in the HTTP POST headers the form field values. These include the
hidden form field values (such as __VIEWSTATE), along with the value
from the txtName TextBox.

When the ASP.NET Web page is posted back, in the load postback data
stage the Page class sees that one of the posted back form fields
corresponds IPostBackDataHandler interface. There is such a control in
the hierarchy, so the TextBox’s LoadPostData() method is invoked,
passing in the value the user entered into the TextBox (“Hello,
World!”). The TextBox’s LoadPostData() method simply assigns this
passed in value to its Text property.

Notice that in our discussion on the load postback data stage, there was
no mention of view state. Therefore, you might naturally be wondering
why I bothered to mention the load postback data stage in an article
about view state. The reason is to note the absence of view state in
this stage. It is a common misconception among developers that view
state is somehow responsible for having TextBoxes, CheckBoxes,
DropDownLists, and other Web controls remember their values across
postback. This is not the case, as the values are identified via posted
back form field values, and assigned in the LoadPostData() method for
those controls that implement IPostBackDataHandler.

Stage 4 – Load
This is the stage all ASP.NET developers are familiar with, as we’ve all
created an event handler for a page’s Load event (Page_Load). When the
Load event fires, the view state has been loaded (from stage 2, Load
View State) along with the postback data (from stage 3, Load Postback
Data). If the page has been posted back, when the Load event fires we
know that the page has been restored to its state from the previous page
visit.

Stage 5 – Raise Postback Event
Certain server controls raise events with respect to changes that
occurred between postbacks. For example, the DropDownList Web control
has a SelectedIndexChanged event that fires if the DropDownList’s
SelectedIndex has changed from the SelectedIndex value in the previous
page load. Another example: if the Web Form was posted back due to a
Button Web control being clicked, the Button’s Click event is fired
during this stage.

There are two flavors of postback events. The first is a changed event.
This event fires when some piece of data is changed between postbacks.
An example is the DropDownLists SelectedIndexChanged event, or the
TextBox’s TextChanged event. Server controls that provide changed
events must implement the IPostBackDataHandler interface. The other
flavor of postback events are raised events. These are events that are
raised by the server control for whatever reason the control sees fit.
For example, the Button Web control raises the Click event when it is
clicked; the Calendar control raises the VisibleMonthChanged event when
the user moves to another month. Controls that fire raised events must
implement the IPostBackEventHandler interface.

Since this stage inspects postback data to determine if any events need
to be raised, the stage only occurs when the page has been posted back.
As with the load postback data stage, the raise postback event stage
does not use view state information at all. Whether or not an event is
raised depends on the data posted back in the form fields.

Stage 6 – Save View State
In the save view state stage, the Page class constructs the page’s view
state, which represents the state that must persist across postbacks.
The page accomplishes this by recursively calling the SaveViewState()
method of the controls in its control hierarchy. This combined, saved
state is then serialized into a base-64 encoded string. In stage 7,
when the page’s Web Form is rendered, the view state is persisted in the
page as a hidden form field.

Stage 7 – Render
In the render stage the HTML that is emitted to the client requesting
the page is generated. The Page class accomplishes this by recursively
invoking the RenderControl() method of each of the controls in its
hierarchy.

These seven stages are the most important stages with respect to
understanding view state. (Note that I did omit a couple of stages,
such as the PreRender and Unload stages.) As you continue through the
article, keep in mind that every single time an ASP.NET Web page is
requested, it proceeds through these series of stages.



--

Scott Mitchell
(e-mail address removed)
http://www.4GuysFromRolla.com
http://www.ASPFAQs.com
http://www.ASPMessageboard.com

* When you think ASP, think 4GuysFromRolla.com!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top