Web Forms Page Processing
In general, the life cycle for a Web Forms page is similar to that of any Web process that runs on the server. Certain characteristics of Web processing — information passed via HTTP protocol, the stateless nature of Web pages, and so on — apply to Web Forms pages just as they do to most Web applications.
However, the ASP.NET page framework performs many Web application services for you. For example, the ASP.NET page framework captures information posted with the Web Forms page, extracts the relevant values, and makes the information accessible via object properties.
It is important to understand the sequence of events that occurs when a Web Forms page is processed. This knowledge will help you program your Web Forms pages and Web applications more effectively.
The Life Cycle of a Web Forms Page
You might find it helpful to understand some fundamental characteristics of how Web Forms pages work in Web applications before you examine the details of what goes on inside a page when it is processed.
One of the most important things to understand is the division of labor in a Web Forms page. The browser presents the user with a form, and the user interacts with the form, causing the form to post back to the server. However, since all processing that interacts with server components must occur on the server, this means that for each action that requires processing, the form must be posted to the server, processed, and returned to the browser. This sequence of events is referred to as a round trip.
Note You can create client script in Web Forms, which is useful for user input validation and for some types of UI programming. Client script does not interact with server components.
Imagine a business scenario: A user enters an order and you want to confirm sufficient inventory for the order, so your application posts the page to the server at an appropriate point in the user's order-entry process. A server process examines the order, performs an inventory lookup, perhaps takes some action defined in business logic (such as modifying the page to indicate an error), and then returns the page to the browser for the user to continue.
In Web Forms, most user actions — such as clicking a button — result in a round trip. For that reason, the events available in ASP.NET server controls are usually limited to click-type events. Most server controls expose a click event, one that requires an explicit user gesture.
By the same token, server controls do not expose high-frequency events such as onmouseover, because each time such an event is raised, another round trip to the server would occur, which would considerably affect response time in the form.
Recreating the Page (View State and State Management)
In any Web scenario, pages are recreated with every round trip. As soon as the server finishes processing and sending the page to the browser, it discards the page information. By freeing server resources after each request, a Web application can scale to support hundreds or thousands of simultaneous users. The next time the page is posted, the server starts over in creating and processing it, and for this reason, Web pages are said to be stateless — the values of a page's variables and controls are not preserved on the server.
Note The server can be configured to cache page information to optimize the pages, but for purposes of application programming, it is clearest to think of them as being disposed of as soon as the server has finished processing them.
In a traditional Web application, the only information that the server has about a form is the information that the user has added to the controls on the form, because that information is sent to the server when the form is posted. Other information, such as variable values and property settings, is discarded.
ASP.NET works around these limitations in the following ways:
- It saves page and control properties between round trips. This is referred to as saving the view state of the control.
- It provides state management facilities so you can save your own variable and application-specific or session-specific information between round trips.
- It can detect when a form is requested for the first time versus when the form is posted, which allows you to program accordingly. You may want a different behavior during a page postback versus an initial request.
Benefits of an Event-Driven Model versus a Linear Processing Model
If you have experience using Active Server Pages (ASP), you recognize that ASP is a linear processing model. An ASP page is processed in a top-to-bottom sequence. Each line of ASP code and static HTML is processed in sequence as it appears in the file. User actions cause the page to be posted to the server in a round trip. Since this action causes a round trip, the server must recreate the page. After the page is recreated, it is processed in the same top-to-bottom sequence as before, and therefore the page is not exhibiting truly event-driven behavior. To create an event-driven experience, you need to explicitly design it. In addition, you have to explicitly maintain page and control state at the most basic level. This model limits the richness of the user interfaces that can be assembled, and it increases the complexity of the code needed to support it.
In comparison, an event-driven model, as in a traditional Visual Basic application, contains programmable elements that are initialized and displayed on the form. Users interact with the elements, which cause events to be raised that in turn call event handlers. This model supports true event-driven behavior, which, by design, greatly extends the richness of the user interfaces that can be assembled, and it reduces the complexity of the code needed to support it.
ASP.NET replaces the linear processing model of ASP by emulating the behavior of an event-driven model. The ASP.NET page framework is provided to implicitly make the associations of an event to an event handler for you. Using the page framework allows you to easily create a user interface that reacts to user actions. For details on creating and using events and event handlers, see Server Event Handling in Web Forms Pages.
In addition, this same framework eases the implementation of page and control state management. For more information on state management, see Web Forms State Management.
For example, ASP.NET allows you to set up event handlers in server code for events that are passed from the browser. Assume the user is interacting with a Web Forms page that contains one button server control. The user clicks the button control and an event is raised that is transmitted via an HTTP post to the server where the ASP.NET page framework interprets the posted information and associates the raised event with an appropriate event handler. This event handler can be a default handler supplied by ASP.NET or it can be your custom implementation. The framework automatically calls the appropriate event handler for the button as part of the framework's normal processing. As a result, you no longer need to explicitly design event-like behavior into a linear processing model. For more information on Web Forms event handling, see ASP.NET Server Control Event Model.
Stages in Web Forms Processing
The ASP.NET page framework processes Web Forms pages in distinct stages. During each stage of Web Forms processing, events may be raised, and any event handler that corresponds to the event runs. These methods provide you with entry points — hooks — that allow you to update the contents of the Web Forms page.
The table below lists the most common stages of page processing, the events raised when they occur, and typical uses at each stage. These stages are repeated each time the form is requested or posted. The Page.IsPostBack property allows you to test whether the page is being processed for the first time.
Note There are several more stages of Web Forms page processing than are listed in the following table. However, they are not used for most page processing scenarios. Instead, they are primarily used by server controls on the Web Forms page to initialize and render themselves. If you intend to write your own ASP.NET server controls, you need to understand more about these stages. For details about the complete set of page processing stages, see Developing ASP.NET Server Controls.
|ASP.NET Page Framework Initialization||The page's Page_Init event is raised, and the page and control view state are restored.||During this event, the ASP.NET page framework restores the control properties and postback data.|
|User Code Initialization||The page's Page_Load event is raised.||Read and restore values stored previously:
|Validation||The Validate method of any validator Web server controls is invoked to perform the control's specified validation.||(There is no user hook at this stage. You can test the outcome of validation in an event handler.)|
|Event Handling||If the page was called in response to a form event, the corresponding event handler in the page is called during this stage.||Perform your application-specific processing:
|Cleanup||The Page_Unload event is called because the page has finished rendering and is ready to be discarded.||Perform final cleanup work:
Introduction to Validating User Input in Web Forms | Data Access in Web Forms Pages | ASP.NET Server Control Event Model | Introduction to Web Forms State Management | ASP.NET State Management | Web Forms Pages