Introduction

Server controls are essentially classes that render specific HTML/JavaScript to the browser. A server control maps to one or many more HTML elements, but provide additional capabilities as well. They also have advanced server-side capabilities, such as responding to postbacks, performing javascript callbacks, databinding assignments, and other advanced capabilities.

Server Control HTML Rendering

.NET comes with a bunch of server controls. A server control is essentially a combination of HTML elements, usually used with JavaScript or other code that works with the server code by posting back to the page and executing the appropriate script. Let’s break that down a little bit. For instance, the ASP.NET Textbox control maps to the <input type=”text”> HTML element. Behind the scenes, the control uses JavaScript to map client-side events to the server-side code. This is more apparent with the ASP.NET LinkButton control; this control uses the href property of the link to store JavaScript code that fires the Click event. All of this mapping is automatic; as a page developer, you only have to worry about the server-side code.

However, there are more complex controls, like the GridView control. This is a composite control, as it makes use of several controls. On the client-side, the GridView maps to an HTML table, as well as several more specific elements in the <td> and <th> tags, such as <span> or <input type="text"> for editing.

Server Side Capabilities

Even though a server control is client-side, the code is actually server-side. It has properties, methods, and events that can be exposed to an ASP.NET page. Some properties map to client-side HTML attributes, where some are strictly server-side, or affect the rendering of the control. Rendering is the process of taking the server-side attributes and creating the HTML for it. This is most important when creating custom controls; however, that is out of the range of this introduction. You won't need to know how that works. Just know that it does work. So, we have properties for that, and we have methods that tap into the page lifecycle (mostly for server-side controls), or for general use. So what are events for? Events map to certain actions. For instance, when the control is loaded in the page, the Load event occurs, similar to the Page Load event. But for the LinkButton control, how does the Click event work? Click maps to clicking the hyperlink, by using javascript. It creates a javascript in the href property that signals to the framework to post the page back to the server. When this occurs, the page life cycles through, and the LinkButton Click event triggers, allowing you to perform server-side manipulations to other controls. You could write a value to a Label control, change the color of the LinkButton, or whatever else you need to do. I'm explaining the internal implementation; remember, you don't need to do anything specific at all with this. The framework manages it all for you. You can see that in the previous example; the link button renders as a hyperlink with a href of javascript:__doPostBack('lnkProcess',''), meaning that the internal JavaScript method will post back for the control with the 'lnkProcess' id, or our LinkButton.

For more information about server controls, check out this MSDN article.

Other Controls

Data Source Controls are a means to quickly setup a connection to a database or data object. They provide a means to select, insert, update, and delete data, and are tightly integrated with the data-bound controls also in the framework (like the GridView and DetailsView controls). Data Source Controls can connect to a SQL database (SqlDataSource), Access Database (AccessDataSource), a custom business class returning a datatable or dataset (ObjectDataSource), an XML file (XmlDataSource), and to a web.sitemap file (SiteMapDataSource).

For more information on Data Source controls, see this MSDN article.

Data-Bound Controls are controls that can take a data source, or link to a data source control (through the DataSourceID property). These controls perform advanced capabilities, such as displaying rows of data in an Excel-like grid. They work by mapping the parameters in the data source to columns/fields in the control itself, either though specific classes (such as the DataControlField class that is the base class of all fields), or through binding statements using the <%# %> notation and the Eval method (a method of the Page class). You often see the databinding notation used when using a template.

For more information about data-bound controls, check out this article on MDSN, detailing the main data-bound controls.

Validation controls hook into other input controls on the page to ensure that the value you are providing it is allowable. For instance, the required field validator ensures that text is present in the form, whereas the regular expression validator doesn't care if there is data in the form, but rather that the data provided matches a specific validation criteria. Validation triggers whenever a button is clicked that has causesvalidation="true", or if the Validate() method is manually called for the Page or the validation control itself. Validation controls ensure that the data is valid; furthermore, validation controls can be setup to work within a specific validation group; that is, whatever server controls define a value for the validationgroup property (any string value can be provided), the button that matches the controls with that validation group is only validated, not the other controls.

For more information on validation groups, see this QUE Publishing article.

Authoring Custom Controls

Authoring Custom Controls is out of the scope of this article, but if you are looking for more information, check out these tutorials at GotDotNet to help you get started.

Summary

As you can see, server controls are essentially server logic that represent HTML/JavaScript on the page. There are various kinds of server controls that are available to you, from data-bound controls to validation controls. Information has been provided to take the learning to a deeper level.

Part 1

Read part 1: Introduction to ASP.NET Development, Part 1 - The Page

About Brian Mains

Brian Mains is an application developer consultant with Computer Aid Inc. He formerly worked with the Department of Public Welfare. In both places of business, he developed both windows and web applications, small and large, using the latest .NET technologies. In addition, he had spent many hou... This author has published 73 articles on DotNetSlackers. View other articles or the complete profile here.