Export (0) Print
Expand All

Web Forms Page Processing

Visual Studio .NET 2003

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.

Round Trips

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.

Round Trip

wf922ts9.vbwebformsroundtrip(en-us,VS.71).gif

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.
StageMeaningTypical uses
ASP.NET Page Framework InitializationThe 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 InitializationThe page's Page_Load event is raised.Read and restore values stored previously:
  • Using the Page.IsPostBack property, check whether this is the first time the page is being processed.
  • If this is the first time the page is being processed, perform initial data binding.
  • Otherwise, restore control values.
  • Read and update control properties.
ValidationThe 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 HandlingIf 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:
  • Handle the specific event raised.
    Note   Events are not raised in a particular order, except that cached control events — as specified by the control's AutoPostBack property — are always processed before the posting event.
  • If the page contains Types of Validation for ASP.NET Server Controls, check the IsValid property for the page and for individual validation controls.
  • Manually save the state of page variables that you are maintaining yourself.
  • Check the IsValid property of the page or of individual validation controls.
  • Manually save the state of controls dynamically added to the page.
CleanupThe Page_Unload event is called because the page has finished rendering and is ready to be discarded.Perform final cleanup work:
  • Closing files.
  • Closing database connections.
  • Discarding objects.
    Note   It is important that expensive resources, such as database connections, be explicitly closed. Otherwise, they will remain open until the next garbage collection occurs. On a heavily loaded server, many open resources can adversely affect performance.

See Also

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

Show:
© 2014 Microsoft