2.1 Server-Side Controls | Essential ASP.NET with Examples in Visual Basic .NET

Much like desktop application development models, the Web Forms model is constructed from a set of primitive controls. They are referred to as server-side controls in ASP.NET because even though they are rendered to the client as HTML, they exist on the server. The best way to understand server-side controls is to see them in action, so consider the page shown in Listing 2-1.

Listing 2-1 An ASP.NET Page Using Server-Side Controls

 <!-- WebFormPage1.aspx --> <%@ Page Language="VB" %> <html> <body>   <form runat=server>     Enter name: <input type=text id=_name runat=server/>     <br/>     Personality: <select id=_personality runat=server>                    <option>extraverted</option>                    <option>introverted</option>                    <option>in-between</option>                  </select>     <input type=submit value="Submit" />     <p>       <% If IsPostBack Then %>         Hi <%=_name.Value%>, you selected            <%=_personality.Value%>       <% End If %>     </p>   </form> </body> </html>

In many respects, this looks like a traditional ASP page you might write with interspersed server-side code. There are two significant differences, however. First, note that the form, input, and select elements on the page have been marked with a runat=server attribute, an attribute usually reserved for differentiating client-side and server-side script blocks. Second, notice that within the paragraph element at the bottom of the page, we were able to reference the value attribute of the input and select elements within server-side evaluation blocks ( <%= %> ). In a traditional ASP page, these expressions would have no meaning on the server. To retrieve the values of the input and select elements, you would look at the request string for variables whose names matched the identifiers of the two controls. We were also able to test the Boolean value IsPostBack to find out whether this was an initial GET request issued by the client or a subsequent POST back to our page.

In ASP.NET any HTML element can now have the runat=server attribute applied to it. When an element is marked with this attribute, ASP.NET creates a server-side control during page compilation and adds it as a field to the Page -derived class. The type of the control depends on the element marked as server-side. Listing 2-2 shows the fields that would be created in the Page -derived class created from the .aspx file from Listing 2-1.

Listing 2-2 Generated Page-Derived Class with Server-Side Controls

 Imports System.Web.UI Imports System.Web.UI.HtmlControls Imports System.Web.UI.WebControls Public Class WebFormPage1_aspx   Inherits Page   Protected _name As HtmlInputText   Protected  __control3 As ListItem   Protected __control4 As ListItem   Protected __control5 As ListItem   Protected _personality As HtmlSelect   Protected __control2 As HtmlForm   ' ... End Class

These server-side controls added to the Page -derived class for our page are initialized with the values entered by the client when a post-back occurs. Furthermore, any modifications to the state of these controls is reflected when the page renders a response to the client. As developers, we can now manipulate controls and their state in a similar fashion to the way desktop controls can be manipulated.

Figure 2-3 enumerates the steps of a client-server interaction when server-side controls are used. Initially (step 1), the client makes a GET request for our page. ASP.NET services this request by creating an instance of our Page -derived class. Because this is an initial request for the page and there are no accompanying POST variables with the request, the values of the server-side controls in our page are set to their defaults (empty strings in this case). At step 2, our Page -derived class instance renders itself into the response buffer, and that response is returned to the client in step 3. The client is now presented with our initial form, and can manipulate and add values to all the controls on the form (step 4). When the user presses the Submit button, a POST request is made to the server, with the values of the controls in the form passed as POST variables (step 5). This time, when ASP.NET creates a new instance of our Page -derived class, it notices that the request was a POST request with accompanying POST variables, so it passes the body of the POST request to the page and asks it to restore the state of any server-side controls (step 6). Our Page -derived class extracts the _name and _personality variables from the POST body and initializes the data members of the class corresponding to those variables with the variable values. This time, when the Page -derived class renders itself (step 7) the server-side controls render themselves with their current contents, which are the same as the values submitted by the client in step 5 unless we change them on the server. In step 8, the client receives the response to the POST with the controls rendered with their current state.

Figure 2-3. Client-Server Interaction with Web Forms

graphics/02fig03.gif

One useful facet of this model is that controls marked with the runat=server attribute retain their state across post-backs to the same page. In traditional ASP pages, you must take explicit action to get this behavior, but it falls naturally out of the Web Forms model.