An ASP.NET server control represents a UI element on the page that displays information, like a label, or collects information, like a text box. You program a server control by manipulating its methods and properties and responding to its events, just as you would program a control in a GUI application.
The WebForms infrastructure manages roundtrips between the browser and the server and largely masks the fact that you’re programming a Web application. ASP.NET provides two sets of server controls: HTML server controls and Web server controls. In this article, I’ll demonstrate both types of server controls to illustrate their similarities and differences.
When talking about programming ASP.NET Web pages, you need to understand two pieces: the element you place in the page and the corresponding .NET server control class that provides the methods and properties to manipulate that element. Separating the page UI from the logic means that the element goes in the .aspx file, and the object reference field for an instance of the corresponding server control class is declared inside the logic class. This is implemented in a language that supports .NET, such as C# (.cs) or Visual Basic.NET (.vb).
The ASP.NET runtime generates a .NET class from the .aspx file. This generated UI class is derived from the logic class. The name of the logic class is specified through the Inherits attribute in the @ Page directive at the top of the .aspx file. The element’s id attribute is given the same name as the server control object reference field in the logic class. The server control object reference field is typically declared with at least protected access to make it available to the derived UI class.
When the page is requested, an instance of the UI class is created on the server. A server control object is created for each element on the page that specifies the runat=”server” and the object reference is stored in the corresponding field in the logic class. This enables the logic class methods, such as event handlers, to manipulate the elements created by the UI class. The linkage between the UI and logic classes and between the page element and the server control object reference is shown in Figure A.
|Linkage to the server control reference|
HTML server controls
The user interface server controls provided with ASP.NET live under the System.Web.UI namespace, with HTML server controls in the System.Web.UI.HtmlControls namespace. Let’s take a look at a simple page implemented with HTML server controls. The HtmlGreeter page prompts users for their name and then issues a greeting. The page UI is in HtmlGreeter.aspx, in Listing A, and the page logic is in HtmlGreeter.aspx.cs, in Listing B. The initial render is shown in Figure B, with the response in Figure C.
|Prompt for user name|
|Greeting issued by HtmlGreeter|
An HTML server control manipulates a standard HTML element that contains the runat=”server” attribute. HtmlGreeter contains four elements that are manipulated programmatically:
- · A <font> element for a header
- · A <b> element to label the text box
- · A text <input> element to collect the user’s name
- · A submit <input> element to submit the page
The id attribute of each element associates it with an HTML server control reference field in HtmlGreeterLogic. Notice that the OnServerClick attribute in the <input> submit element declaratively attaches the HtmlGreeterLogic.Button_Click event handler method to the <input> submit button’s click event.
There isn’t a one-to-one mapping between an HTML element and the HTML server control used to program it. There are currently about 16 HTML server controls, but there are far more HTML elements. Several HTML server controls program two or more HTML elements. For example, an HtmlInputText control can program an <input type=”text”> element, as it does in HtmlGreeter, but it can also program an <input type=”password”> element. The most versatile HTML server control is, not surprisingly, HtmlGenericControl. In the HtmlGreeter page, HtmlGenericControl is used to program <font> and <b> (bold) elements. The Table A lists several of the more common HTML server controls and the HTML elements that they program.
|Common HTML server controls|
Constructing a page with HTML elements and programming those elements with HTML server controls allows you to determine what is sent to the browser. The HTML elements you specify are sent to the browser, minus server-side attributes such as runat=”server” and any server-side programmatic modifications.
Web Server Controls
Now let’s reimplement the greeter page using Web server controls rather than HTML server controls. Web Server controls live in the System.Web.UI.WebControls namespace. The AspGreeter page UI is in AspGreeter.aspx, in Listing C. The page logic is in AspGreeter.aspx.cs, in Listing D. As with the HTML elements, a Web server control page element must contain a runat=”server” attribute to be programmable on the server side. Unlike HTML elements, there is a one-to-one mapping between the page element and the Web server control class used to program the element.
For the most part, the elements in AspGreeter look and behave like standard HTML elements. There are a few differences. For instance, each element tag name in AspGreeter is prefixed with the asp: XML tag to refer to the ASP namespace. There is some flexibility in specifying the content for a <asp:Label>. I chose to specify the content through the Text attribute and close the start tag with />. Alternatively, I could have added a </asp:Label> end tag and specified content as the element’s inner text. You have the same option when specifying an initial value for a TextBox control.
Beyond the basics
While the Web server controls used in AspGreeter are nearly equivalent to standard HTML elements, other Web server controls provide much more sophisticated functionality. Table B lists some of the highlights.
|Select Web server controls|
The AdRotator selects a banner advertisement from a collection and displays it. The Calendar control displays a single-month calendar to enable the selection of a date, similar to the MSCAL.Calendar ActiveX control.
DataGrid and Repeater are data-bound controls that display items from a data source, such as an ADO.NET DataSet. DataGrid displays data source items in a table, while Repeater displays data source items using a custom layout. Together with the other data-bound Web server controls, you have an enormous amount of flexibility for presenting data. However, using data-bound controls is a topic for another time.
You’re free to mix HTML and Web server controls on the same page. But while the HTML element that you specify will be the element rendered when the page is sent to a browser, Web server controls render themselves based on the capabilities of the browser. For example, a complex Web server control, like a DataGrid, rendered to target an up-level browser may include client-side scripting for better responsiveness. The same control rendered to target a mobile device may make a round trip to the server to accomplish the same task.
Is ASP.NET a step in the right direction?
ASP.NET represents a complete rethinking. Are these changes an improvement for you? What do you like most about ASP.NET? Send us an e-mail with your thoughts and experiences or post a comment below.