Using the BarChart Control
The first step to import a custom control in an ASP.NET page is add a @Register
directive to make the control visible to the ASP.NET runtime.
<%@ Register TagPrefix="expo"
attribute can take an arbitrary string. The same is not true for the other two attributes which will be set to the control's namespace and assembly name respectively. Here's a styled BarChart control that looks like Figure 1
<expo:barchart id="BarChart1" runat="server"
<LabelStyle Font-Bold="True" Width="80px" />
To bind the control to its data, you use the following code:
DataTable data = ExecuteQuery(1997);
BarChart1.Maximum = 150000;
BarChart1.Title = "Northwind Sales";
BarChart1.SubTitle = "(Year 1997)";
BarChart1.DataSource = data.DefaultView;
BarChart1.DataTextField = "Employee";
BarChart1.DataValueField = "Sales";
The sample page runs a query against the Northwind database and obtains a result set with at least two columnsEmployee
. The former is bound as the label; the latter end up feeding the bar. The Maximum
property defines the scale for the graph.
Although it is fairly complex already, the BarChart control only scratches the surface of a real-world data-bound control. It lacks at least three key features: events, templates, and designers. Let me briefly review the benefits of each, and related development issues.
The control should fire a couple of events at the very minimumItemCreated
. The former is meant to indicate when an item of a given type (title, subtitle, item) is created; the latter informs when data has been bound to the bars. By wiring some custom code up to these events, you can apply context-sensitive changes and, for example, change the color of bars if the represented value exceeds a given threshold. The source code of the BarChart control clearly indicates where events should be fired.
Templates are an interesting add-on feature that you can implement to let developers customize at least header and footer. Required changes don't prefigure a significant effort. For each template, you add a property and a standard if
block in the routines that create the item. The if
block looks at the template property and decides whether the template should be instantiated in lieu of the default layout.
Finally, I want to mention design-time features. As is, the control doesn't provide a WYSIWYG experience. To make up for this, you need to create a custom designera class that inherits from ControlDesigner and overrides quite a few methods. The overridden methods will basically return the HTML to display in the Visual Studio .NET site.
Real-world data-bound controls are not for the faint-hearted. They require deep knowledge of the ASP.NET internals and familiarity with attributes and base classes. In this article, I built a non-toy control from scratch and added a good deal of features. More importantly, along the way I tried to emphasize pitfalls and caveats that could compromise your efforts, which happened to me several times.
All in all, the good news is that ASP.NET 2.0 is just around the corner and it will bring a full bag of goodies for ASP.NET control developers. Sure, you'll find new and improved controls but also new and improved base classes to build custom data-bound controls more quickly, effectively, and with a dramatically reduced surface for bugs and programming errors.