Introduction to Programming ASP.NET Web Forms Pages
ASP.NET Web Forms pages allow you to create dynamic content for your Web application. With a static HTML page (.htm or .html file), the server fulfills a Web request by reading the file and sending it as-is to the browser. In contrast, when someone requests an ASP.NET Web Forms page (.aspx file), the page runs as a program on the Web server. While the page is running, it can perform any task that your Web site requires, including calculating values, reading or writing database information, or calling other programs. As its output, the page dynamically produces markup (elements in HTML or another markup language) and sends this dynamic output to the browser.
This topic provides an overview of the fundamental characteristics of how ASP.NET Web Forms pages work.
Note
This topic applies only to ASP.NET Web Forms pages. It does not apply to pages that you create using ASP.NET MVC (Model View Controller) or ASP.NET Web Pages.
Postbacks and Round Trips
ASP.NET Web Forms pages run as code on the server. Therefore, for the page to be processed, the page is configured to submit to the server when users click buttons (or optionally, when users select check boxes or interact with other controls in the page). Each time, the page is submitted back to itself so it can run its server code again and then render a new version of itself back to the user.
The processing cycle for an ASP.NET Web Forms page is this:
The user requests the .aspx page. (The page is requested using an HTTP GET method.) The page runs for the first time, performing preliminary processing if you have programmed it to do so.
The page dynamically renders markup to the browser, which the user sees as a Web page similar to any other page.
The user types information or selects from available choices and then clicks a button. (If users click a link instead of a button, the page might simply navigate to another page, and no further processing takes place on the first page.)
The page is posted to the Web server. (The browser performs an HTTP POST method, which in ASP.NET is referred to as a postback.) Specifically, the page is posted back to itself. For example, if the user is working with the page Default.aspx, clicking a button on the page posts the page back to the server with a target of Default.aspx.
On the Web server, the page runs again. The information that the user typed or selected is available to the page.
The page performs the processing that you have programmed it to do.
The page renders itself back to the browser.
This cycle continues as long as the user is working in the page. Each time the user clicks a button, the information in the page is posted to the Web server and the page runs again. Each cycle is referred to as a round trip. Because page processing occurs on the Web server, each action that the page can do requires a round trip to the server.
Note
An ASP.NET Web Forms page can run client script, which does not require a round trip to the server, and which is useful for user input validation and for some types of UI programming. For more information, see Client Script in ASP.NET Web Pages.
Cross-Page Posting
Under some circumstances, you might want a Web Forms page to post to a different page, not to itself. This is referred to as cross-page posting. For example, you might be creating a series of pages that process a customer order. Each page can post to the next page in the sequence. For more information, see Cross-Page Posting in ASP.NET Web Forms.
Page Lifetime
Unlike forms in desktop applications, an ASP.NET Web Forms page does not start up, run while the user works with the form, and then unload only when the user clicks a Close button. This is because the Web is inherently disconnected. When a browser requests a page from a Web server, the browser and the server are connected only long enough to process the request. After the Web server has rendered a page to the browser, the connection is terminated. If the browser makes another request to the same Web server, even for the same page, this request is processed as a new request.
The disconnected nature of the Web dictates the way an ASP.NET page runs. When a user requests an ASP.NET Web Forms page, a new instance of the page is created. The page performs its processing, renders markup to the browser, and is then discarded. If the user clicks a button to perform a postback, a new instance of the page is created, the page performs its processing, and is again discarded. Thus, each postback and round trip results in a new instance of the page.
For more information, see ASP.NET Web Forms Pages.
Preserving Page State
In normal HTTP protocol, the only information that the server has about a page is the information that the user has specified using controls on the page, because the browser sends only that information to the server when the page is posted. Other information, such as variable values and property settings, is discarded. ASP.NET helps preserve other page information in the following ways:
ASP.NET saves the state (properties) of server controls between round trips, which is called saving control state.
ASP.NET provides state management capabilities so you can save your own variables and application-specific or session-specific information between round trips.
ASP.NET can detect when a page is requested for the first time and when the page is posted, which allows you to program accordingly. For instance, you might want to read information from a database the first time a page is displayed, but not on every postback.
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 pages as being disposed of as soon as the server has finished processing them.
For more information, see ASP.NET State Management Overview.
Programming ASP.NET Web Forms Pages
You can create the server code for your ASP.NET Web Forms pages using Visual C# or Visual Basic or other languages that are supported in the .NET Framework. ASP.NET Web Forms pages can contain client script that runs within the browser. Some ASP.NET functions generate client script and inject it into the page. In that case, ASP.NET always generates ECMAScript (JavaScript) for best cross-browser functionality. In addition, you can add your own client script for custom functionality. If you do, you can use any client script language that is compatible with the browsers you are targeting.
Server Controls
Like any Web page, ASP.NET Web Forms pages can contain static text. Most often, however, you will add controls to the page, such as text boxes, check boxes, and buttons. These controls allow the user to interact with the page and send information to the server when the page is posted back.
ASP.NET provides a collection of controls known as Web server controls. ASP.NET server controls can be similar to corresponding HTML form elements. For example, the ASP.NET TextBox control is similar to an HTML <input type="text"> element. However, ASP.NET server controls offer a richer programming experience than HTML elements. There are also ASP.NET server controls for a much wider range of functions than what is offered by HTML elements. Among the server controls you can use on an ASP.NET Web page are a calendar control, data-bound controls that display lists or grids, a login control to add security to your site, and many more.
For more information, see ASP.NET Web Server Controls Overview.
Page and Server Control Events
An ASP.NET Web Forms page and the server controls on it support an event model like that found in client applications. For example, when users click a Button server control on an ASP.NET Web Forms page, the page is posted back to the server, the page is recreated, and a click event is raised. You can add code to the page that responds to this click event.
The page itself raises life cycle events when it is initialized, such as the Page_Init and Page_Load events, which gives you an opportunity to run code when the page starts up. (Remember that the page is created and reinitialized with each round trip.) Individual controls can raise their own events. Button controls raise a Click event, check box and radio button controls raise a CheckedChanged event, and list box and drop-down list controls raise a SelectedIndexChanged event. Some controls, such as the Calendar control, raise events that are more abstract than simple click events. For example, the Calendar control raises a VisibleMonthChanged event when users navigate to a different month.
Most ASP.NET server controls support only a few events that you can handle in server code. To process an event, the page must perform a round trip so that the user's choice can be sent to the page for processing. 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 page. However, you can configure ASP.NET server controls to raise client-side events such as onmouseover. In that case, the controls do not post back to the server, and you create client script to respond to the events.
For more information about creating and using events and event handlers, see Server Event Handling in ASP.NET Web Forms Pages.
Browser Compatibility
Because ASP.NET Web page processing occurs on the Web server, ASP.NET Web Forms pages are compatible with any browser or mobile device. A Web Forms page automatically renders the correct browser-compliant markup (XHTML or other markup language) for features such as styles and layout. Alternatively, you can create Web Forms pages with controls that are specifically designed to render output for specific devices, such as mobile phones. For more information, see Creating ASP.NET Mobile Web Pages.