The ASP.NET Page and Postback Model

ASP.NET provides a Web page execution model that differs considerably from the approaches taken previously. Instead of executing chunks of code at the appropriate stages of sending the page to the client, ASP.NET treats the page as a Class (in code terms) and compiles it into Microsoft Intermediate Language code (MSIL). This code is stored on disk and then executed by the .NET Framework Just-In-Time (JIT) runtime system when requested by a user. This provides fast and efficient performance, but it also enables the use of new (in terms of Web development) programming techniques.

Differentiating between Postback and Navigate

One of the fundamental actions in a Web page is the user clicking a link or button that performs some action. Traditionally, this would take them to a different page. This page might handle the values submitted by the user if they clicked a Submit button, or it may just be the next page of content that they wish to view. However, as you saw in the section Hyperlink and Navigation Controls, ASP.NET differentiates between these two types of actionscalled postback and navigation.

A postback occurs when the link, button, or some other control on the page causes reloading of the same page, unless you use the cross-page postback feature (described in Chapter 10). This is the default action when you place controls on a Web Form page, because it contains an HTML <form> element that always posts its content back to the same page when submittedyou cannot change this behavior unless you add some clientside script to change the form attributes after the page loads (and this is strongly discouraged).

The ASP.NET Event-Driven Architecture

The result of a postback is that ASP.NET can, using the viewstate information that it inserts into the page, recreate the same series of objects as a Class and re-execute it. By taking into account the values of the controls that are sent with the request when the user submits the page, ASP.NET can figure out if any values in the controls have changed. It can also tell which control caused the postback and whether the postback is, in fact, from the same page (providing some rudimentary security against spoofing by users who create malicious pages that post to your application). From this information, ASP.NET can then raise events within the class, such as the Click event for a Button control or the TextChanged event for a TextBox control. Your code can handle these events, just as you would in a normal executable application built in other languages.

In addition, the values of all the controls (including the values of properties other than the value itself) are available within the page. The viewstate of the page (an encoded string placed into a hidden control in the page when sent to the client) contains these values as well as a representation of the original control tree. This means that ASP.NET automatically maintains the user's selections in lists, text they typed into text boxes, and settings of checkboxes and option buttons, between each postback. This makes a lot of sensein a normal application users do not expect to see all the controls in a window return to their default values each time they click a button. The good news is that, unlike most other Web development environments, there is no need for you to write code to do this in ASP.NET.

Request and Response Information

Just because ASP.NET handles all the manipulation of the values submitted by the client for you does not mean that you lose control. If you have worked with other Web technologies, you will have used the Request and Response objects (or their equivalents) to get at the values submitted from an HTML form. In ASP.NET, these objects are available, though you will generally have no need to query them for control values.

Instead, however, they provide a range of properties that provide other information about the user's request and the response sent by the server. The Request object allows you to discover information about the user, such as their public IP address, and about the page or file that they requestedsuch as the physical path on your server or the individual parts of the URL they provided. The Response object allows you to set specific values for the server's response, such as the content type and encoding and to inject content into the Stream returned to the client.

A full list of the properties, methods, and events for the HttpRequest class, an instance of which implements the ASP.NET Request object, is at http://msdn2.microsoft.com/library/ha0633cx(en-us,vs.80).aspx. The equivalent for the HttpResponse class, which implements the ASP.NET Response object, is at http://msdn2.microsoft.com/library/wfa24xy1(enus,vs.80).aspx. You will see the Request and Response objects used throughout this book, including in the next chapter, where you will explore more features of the ASP.NET page architecture and the design of interactive Web Form pages.