Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Page and control lifecycle

Reply
Thread Tools

Page and control lifecycle

 
 
John Lau
Guest
Posts: n/a
 
      05-11-2004
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


 
Reply With Quote
 
 
 
 
Scott Mitchell [MVP]
Guest
Posts: n/a
 
      05-11-2004
John Lau wrote:
> 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...bjectmodel.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 [(E-Mail Removed)] 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?
<aspropDownList 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>
</aspropDownList>
<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
http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.4GuysFromRolla.com
http://www.ASPFAQs.com
http://www.ASPMessageboard.com

* When you think ASP, think 4GuysFromRolla.com!
 
Reply With Quote
 
 
 
 
John Lau
Guest
Posts: n/a
 
      05-11-2004
Hey Scott,

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

John

"Scott Mitchell [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> John Lau wrote:
> > 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...bjectmodel.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 [(E-Mail Removed)] 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?
> <aspropDownList 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>
> </aspropDownList>
> <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 Removed)
> http://www.4GuysFromRolla.com
> http://www.ASPFAQs.com
> http://www.ASPMessageboard.com
>
> * When you think ASP, think 4GuysFromRolla.com!



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Page lifecycle and dynamic controls Hans Kesting ASP .Net 5 11-03-2008 07:12 PM
Delegates, Events and the Page Lifecycle studio60podcast@gmail.com ASP .Net 5 04-19-2007 06:46 PM
ASPNet Component and Page lifecycle documentation multiformity@gmail.com ASP .Net 0 05-30-2006 06:09 PM
Dynamic Controls in User Control; page/control lifecycle question Frankie ASP .Net 2 06-23-2005 04:07 PM
ASP.NET page lifecycle and In-Line code redhair ASP .Net 1 11-30-2004 03:21 PM



Advertisments