Browse DevX
Sign up for e-mail newsletters from DevX


A Crash Course on Custom ASP.NET Data-bound Controls

Data-bound controls require a data source property and a set of string properties that link to particular columns of the data source. In addition, they need an Items collection property to track all the building blocks of the control's user interface. Finally, a well-done data-bound control supports styles and custom events.

ata-bound controls make ASP.NET programming much easier. They expose a bunch of properties and methods to link their properties to a valid data source and they know how to build their user interface to reflect the contents of the data source. Data-bound controls work by repeating a template for each data row, and they try to optimize their use of system resources such as ViewState. This article guides you to building a real-world, data-bound control that displays a pure HTML bar chart.

Several years ago when the word "online" made most people think only of a bright and kind voice over the phone, I asked a friend about his company's Web site. At the time, my friend was employed by the IT department of a very popular museum engaged in a cutting edge project—publishing digital pictures of their artwork on the Web.

When the framework calls the DataBind method, data-bound controls get fresh data and update their user interface. When this happens, it's a good safety habit to clean up child controls and memory.
The very first version of that site—I really doubt it ever went online—was written using pure HTML. Yes, you got it right-no server-side technologies, no active pages, no data-binding. The site was simply a collection of HTML pages each padded with an <img> tag and a few heading blocks.

We were sipping our espresso coffee at a bar in Rome when he asked the key question. "Do you know of any technologies to help us generalize the structure of the site?" he tentatively asked. As you imagine, they were looking for a tool to read data out of a database and populate some predefined tags in the pages. Moreover, they were really dreaming of the capability of using just one parametric page to show all of the pictures.

No more sardonic grins, please-that was really a cutting edge project for the time. Did I say that there was no version of Active Server Pages (ASP) around yet?

Now, a decade later, we're so accustomed to the idea of data binding and server programming that the idea of building distinct pages with a hard-coded <img> tag for publishing distinct pictures seems absurd.

Data binding has evolved a lot in the past ten years. In this article, I'll explore what it means today to ASP.NET developers and provide a crash course on how to build rich, powerful, and effective custom data-bound controls.

Basics of Data Binding
Data-binding is a technology designed to establish a connection between a data source and a server component. In ASP.NET 1.x, data-binding is a way to link enumerable objects to control properties. By the way, this definition will be enhanced and refined in ASP.NET 2.0 to support more than just enumerable objects as the data source.

In the context of data-binding, data-bound controls are an essential building block. Data-bound controls expose a bunch of properties and methods to link to a valid data source. In addition, a data-bound control is designed to incorporate, in its own user interface, any data it gets from the source.

ASP.NET comes with a number of pre-defined data-bound controls. Examples include the DataGrid, Repeater, DropDownList, and ListBox controls. More importantly, ASP.NET allows you to build your own, custom data-bound controls.

When it comes to building new ASP.NET controls, you have two basic options: inherit from an existing control that already provides most of the features you need, or build your new control from scratch. In most real-world cases, the second option is the only one worth considering. Unfortunately, in real ASP.NET applications, you must either live with the pre-defined data-bound controls or commit to building complex and feature-rich new ones.

The ASP.NET 1.x framework doesn't provide an effective diagram of classes for data-bound controls. For one thing, there's no common base class for all data-bound controls. Some controls, though, are grouped logically on a per-function basis and inherit from intermediate, abstract classes such as ListControl and BaseDataList. The overall design of the diagram is not consistent, however, and doesn't encourage developers to take advantage of it. Add some less-than-perfect documentation and you get a clear picture.

Thankfully, things are going to change with ASP.NET 2.0 as this article from the ASP.NET site reports.

In summary, a custom data-bound control is often a composite control that pumps data out of a source. This control builds its own user interface by composing together various existing controls in a table or flow layout. The control's interface may contain links and buttons and generate events and postbacks. As a control developer, you should use the ViewState but avoid storing too much data there. Finally, the control must be able to redesign itself without requiring fresh data on each postback. In other words, any postback generated outside the control should not empty the data source of the control. This point may sound like an unnecessary remark; it is, instead, just one of the most common pitfalls for control developers.

Thanks for your registration, follow us on our social networks to keep up-to-date