The life cycle for a Web Forms page is, generally speaking, 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 just as they do to other Web applications.

However, the Web Forms framework performs many Web application services for you. As one example, the Web Forms framework captures the information posted with the form, extracts the relevant values, and makes it available to you in object properties.

Even so, it is helpful to understand the sequence of events that occurs when a Web Forms page is processed. This knowledge will help you know how you can program your Web Forms pages effectively.

Before you examine the details of what goes on inside a Web Forms page when it is processed, you might find it helpful to understand some fundamental characteristics of how Web Forms work as Web applications.

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. However, all processing that interacts with other server components must occur on the server. This means that for each action that requires processing, the form must be sent ( posted ) to the server, processed, and returned to the browser. This sequence 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. However, client script does not interact with server components.

For example, if the user enters an order and you want to confirm sufficient inventory for the order, your application posts the page to the server at an appropriate point in the user’s order entry. A server process examines the order, performs an inventory lookup, perhaps takes some action ( 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 Web Forms server controls are limited. Most server controls expose a click event, for example — an event that requires an explicit user gesture. By the same token, server controls do not expose high-frequency events such as onMouseOver, because each time the event is raised, it would require another round trip to the server, which would considerably affect response time in the form.

In any Web processing scenario, pages are created from scratch with every round trip. In effect, as soon as the server finishes processing a page and sends it to the browser, it discards the page information. The next time the page is posted, the server starts all over in creating and processing it. For this reason, Web pages are said to be stateless; that is, the values of a page’s variables and controls are not preserved on the server.

NOTE: In fact, the server might 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, therefore, the only information that the server has about a form is the information that the user has filled into controls, because that information is sent to the server when the form is posted. Other information, such as variable values or property settings, have been discarded.

The Web Forms framework works around these limitations in several ways. First, the Web Forms framework saves page and control properties between round trips, which is referred to as saving the controls’ view state. ( The framework can detect when a form is requested for the first time versus when the form is posted, which allows you to program accordingly. ) In addition, the Web Forms page framework provides state management facilities so you can store other application-specific information ( not just the values of controls ) between round trips or to pass between pages.

In client-side forms, the form is initialized and displayed along with its controls. Users then interact with the form, which causes events to be raised that in turn call event-handling methods.

In traditional server-based Web forms, because user actions cause the form to be posted to the server, and because the server must recreate the page with each round trip, processing is more linear than in a client-side form. Effectively, after being recreated, the page is processed in the same top-to-bottom sequence each time. The result is that the form is not truly event-driven.

The Web Forms framework overcomes this strict linear processing in various ways. For example, the framework allows you to set up event-handling methods in server code for events that occur in the browser. When the user clicks a Button Web Server Control, for example, the button raises an event that is transmitted via a form post to the server. There, the Web Forms framework interprets the post information and as part of its normal processing calls the appropriate process in your code to handle the event. For more details about event handling in Web Forms, see Web Forms Events and Handlers.