Page and control lifecycle

Discussion in 'ASP .Net' started by John Lau, May 11, 2004.

  1. John Lau

    John Lau Guest

    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
     
    John Lau, May 11, 2004
    #1
    1. Advertising

  2. 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-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 [] 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

    http://www.4GuysFromRolla.com
    http://www.ASPFAQs.com
    http://www.ASPMessageboard.com

    * When you think ASP, think 4GuysFromRolla.com!
     
    Scott Mitchell [MVP], May 11, 2004
    #2
    1. Advertising

  3. John Lau

    John Lau Guest

    Hey Scott,

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

    John

    "Scott Mitchell [MVP]" <> wrote in message
    news:...
    > 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-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 [] 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
    >
    > http://www.4GuysFromRolla.com
    > http://www.ASPFAQs.com
    > http://www.ASPMessageboard.com
    >
    > * When you think ASP, think 4GuysFromRolla.com!
     
    John Lau, May 11, 2004
    #3
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. redhair
    Replies:
    1
    Views:
    485
    Scott Allen
    Nov 30, 2004
  2. Frankie
    Replies:
    2
    Views:
    6,037
    Frankie
    Jun 23, 2005
  3. Replies:
    0
    Views:
    355
  4. Replies:
    5
    Views:
    386
  5. Hans Kesting

    Page lifecycle and dynamic controls

    Hans Kesting, Nov 3, 2008, in forum: ASP .Net
    Replies:
    5
    Views:
    507
    Mike Gleason jr Couturier
    Nov 3, 2008
Loading...

Share This Page