March 8, 2011, 7:03 p.m.
posted by roni
A Day in the Life of a Page
The analogy between the desktop control model and Web Forms is not complete. Although the fundamental elements behave similarly, such as rendering of state and event propagation, the Web Forms model has an imposed sequencing on the rendering process that does not exist in the desktop model. It is critical for Web developers using ASP.NET to understand this sequencing in order to use the model effectively.
Pages are short-lived objects, as are all the elements they contain. A page is created for the sole purpose of processing a request, and once that request processing has completed, the page is discarded. This means that each request to a page is processed by a new instance of that Page class. Moreover, an explicit, deterministic sequence of events takes place after the page is created to service a request. This sequence of events is something that every ASP.NET developer should be aware of, because your pages will not behave the way you expect if you perform things in the wrong order. For example, consider the page shown in Listing 2-9.
<!-- File: sample.aspx --> <%@ Page Language="VB" %> <html> <body> <form runat=server> <h2>ASP.NET sample page</h2> <h3>Page type: <span id=_message runat=server/></h3> <% ' Error - modifying a property of a server-side ' control within a script block like this can lead ' to inconsistencies _message.InnerText = this.GetType().ToString() %> </form> </body> </html>
As noted in the comments, the assignment to the InnerText property of the server-side span element has no effect because it falls within a server-side block of code delineated with <%%> tags that is placed after the control that is modified. All server-side code within <%%> tags is added to a Render method of the Page class, as discussed in Chapter 1. By this time, the server-side span has already rendered itself into the response buffer with its inner text set to an empty string, and the assignment has no effect on the output of the page. This is in contrast to a traditional desktop control model, where any modifications made to a control at any time are saved and reflected in that control's rendering.
Figure shows the events that occur during a page's lifetime. As a page developer, you have hooks into most of these events, either by defining event handlers for a particular event or by providing overridden versions of virtual functions defined in the Page base class. Most of the programmatic manipulation of server-side controls should occur either in the Load event handler for a page or within a server-side control event handler. The Load event fires after the all the server-side controls have been created and had their state restored from the POST body of the request. This gives you an opportunity to both view the values submitted by the client, as well as a chance to populate controls with values you want the client to see in the response to this request.