Web server controls can be seen as advanced versions of HTML server controls.
Web server controls are those that generate content for you—you’re no longer in control of the HTML being used. While having good knowledge of HTML is useful, it’s not a necessity for those working with web server controls.
Let’s look at an example. We can use the Label web server control to place simple text inside a web form. To change the Label’s text from within our C# or VB code, we simply set its Text property like so:
Visual Basic
myLabel.Text = "Mickey Mouse"
Similarly, to add a text box to our form, we use the TextBox web server control. Again, we can read or set its text using the Text property:
C#
username = usernameTextBox.Text;
Though we’re applying the TextBox control, ASP.NET still uses an input element behind the scenes; however, we no longer have to worry about this detail. With web server controls, you no longer need to worry about translating the needs of your application into elements you can define in HTML—you can let the ASP.NET framework do the worrying for you.
Unlike HTML server controls, web server controls don’t have a direct, one-to-one correspondence with the HTML elements they generate. For example, we can use either of two web server controls—the DropDownList control, or the ListBox control to generate a select element.
Web server controls follow the same basic pattern as HTML tags, but the tag name is preceded by asp:, and is capitalized using Pascal Casing. Pascal Casing is a form that capitalizes the first character of each word (such as TextBox). The object IDs are usually named using Camel Casing, where the first letter of each word except the first is capitalized (e.g. usernameTextBox).
Consider the following HTML input element, which creates an input text box:
<input type="text" name="usernameTextBox" size="30" />
The equivalent web server control is the TextBox control, and it looks like this:
<asp:TextBox id="usernameTextBox" runat="server" Columns="30">
</asp:TextBox>
Remember that, unlike any normal HTML that you might use in your web forms, web server controls are first processed by the ASP.NET engine, where they’re transformed to HTML. A side effect of this approach is that you must be very careful to always include closing tags (the </asp:TextBox>part above). The HTML parsers of most web browsers are forgiving about badly formatted HTML code, but ASP.NET is not. Remember that you can use the shorthand syntax (/>) if nothing appears between your web server control’s opening and closing tags. As such, you could also write this TextBox like so:
<asp:TextBox id="usernameTextBox" runat="server" Columns="30" />
To sum up, the key points to remember when you’re working with web server controls are:
Web server controls are those that generate content for you—you’re no longer in control of the HTML being used. While having good knowledge of HTML is useful, it’s not a necessity for those working with web server controls.
Let’s look at an example. We can use the Label web server control to place simple text inside a web form. To change the Label’s text from within our C# or VB code, we simply set its Text property like so:
Visual Basic
myLabel.Text = "Mickey Mouse"
Similarly, to add a text box to our form, we use the TextBox web server control. Again, we can read or set its text using the Text property:
C#
username = usernameTextBox.Text;
Though we’re applying the TextBox control, ASP.NET still uses an input element behind the scenes; however, we no longer have to worry about this detail. With web server controls, you no longer need to worry about translating the needs of your application into elements you can define in HTML—you can let the ASP.NET framework do the worrying for you.
Unlike HTML server controls, web server controls don’t have a direct, one-to-one correspondence with the HTML elements they generate. For example, we can use either of two web server controls—the DropDownList control, or the ListBox control to generate a select element.
Web server controls follow the same basic pattern as HTML tags, but the tag name is preceded by asp:, and is capitalized using Pascal Casing. Pascal Casing is a form that capitalizes the first character of each word (such as TextBox). The object IDs are usually named using Camel Casing, where the first letter of each word except the first is capitalized (e.g. usernameTextBox).
Consider the following HTML input element, which creates an input text box:
<input type="text" name="usernameTextBox" size="30" />
The equivalent web server control is the TextBox control, and it looks like this:
<asp:TextBox id="usernameTextBox" runat="server" Columns="30">
</asp:TextBox>
Remember that, unlike any normal HTML that you might use in your web forms, web server controls are first processed by the ASP.NET engine, where they’re transformed to HTML. A side effect of this approach is that you must be very careful to always include closing tags (the </asp:TextBox>part above). The HTML parsers of most web browsers are forgiving about badly formatted HTML code, but ASP.NET is not. Remember that you can use the shorthand syntax (/>) if nothing appears between your web server control’s opening and closing tags. As such, you could also write this TextBox like so:
<asp:TextBox id="usernameTextBox" runat="server" Columns="30" />
To sum up, the key points to remember when you’re working with web server controls are:
- Web server controls must be placed within a <form runat="server"> tag to function properly.
- Web server controls require the runat="server" attribute to function properly.
- We include web server controls in a form using the asp: prefix.
There are more web server controls than HTML controls. Some offer advanced features that simply aren’t available using HTML alone, and some generate quite complex HTML code for you. We’ll meet many web server controls as we work through this and future chapters.
For more information on web server controls, including the properties, methods, and events for each, have a look at Appendix A.
For more information on web server controls, including the properties, methods, and events for each, have a look at Appendix A.