Programming Microsoft ASP.NET 4 - Dino Esposito [4]
There are three pillars to the Web Forms model: page postbacks, view state, and server controls. They work together according to the model depicted in Figure 1-1.
Figure 1-1. The Web Forms model in action.
Each HTTP request that hits the Web server and is mapped to the ASP.NET runtime goes through a number of stages centered on the processing of the postback event. The postback event is the main action that the user expects out of her request.
First, the request is processed to extract preparatory information for the successive postback action. Information includes the state of controls that altogether will produce the final HTML for the page. Following the postback, the HTML response is arranged for the browser, including the new state of controls to be used upon the next request.
All of the server-side steps are wrapped up together according to the definition of the Page Controller pattern. In light of this, each request is seen as processed by a controller entity ultimately responsible for outputting an HTML page. The page controller entity is implemented as a class that fires a few events in the developer’s code, thus giving the developer a way to interact with the request and influence the final output.
To better understand the sense of the Web Forms model and the reasons for its success, look at the following code snippet:
void Button1_Click(Object sender, EventArgs args)
{
Label1.Text = TextBox1.Text;
}
Defined in a Web Forms class, the Button1_Click function represents the handler of a postback event. When the user clicks the HTML element with a matching ID (in this case, Button1), a request occurs that is resolved by running the code just shown. If it weren’t for the stateless nature of the Web protocols, this would be like the standard event-driven programming model that many of us used (and enjoyed) in the early Visual Basic days of the late 1990s.
In the body of the handler method, you can access in a direct manner any other page elements and set its state accordingly as if you were just touching on the user interface. Interestingly enough, though, the preceding code runs on the Web server and needs a bit of extra work to mediate between the client HTML and the server environment. But it works, and it is easy—extraordinarily easy—to understand and apply.
Page Postbacks
An ASP.NET page is based on a single form component that contains all of the input elements the user can interact with. The form can also contain submission elements such as buttons or links.
A form submission sends the content of the current form to a server URL—by default, the same URL of the current page. The action of posting content back to the same page is known as the postback action. In ASP.NET, the page submits any content of its unique form to itself. In other words, the page is a constituent block of the application and contains both a visual interface and some logic to process user gestures.
The click on a submit button or a link instructs the browser to request a new instance of the same page from the Web server. In doing so, the browser also uploads any content available in the (single) page’s form. On the server, the ASP.NET runtime engine processes the request and ends up executing some code. The following code shows the link between the button component and the handler code to run:
The running code is the server-side handler of the original client-side event. From within the handler, the developer can update the user interface by modifying the state of the server controls, as already shown and as reiterated here:
public void Button1_Click(object sender, EventArgs args)
{
// Sets the label to display the content of the text box
Label1.Text = "The textbox contains: " + TextBox1.Text;
}
At the time the handler