Deciding When to Use the DataGrid, DataList or Repeater Part 2
Analyzing the DataList
Recall that the DataGrid renders as an HTML
<table> , which each DataSource record as a table row
(<tr>) and each record field as a table column (
<td>). At times you might want more control over the presentation of data. For example, you might want to have the data displayed in an HTML
<table>, but rather than have one record per row, you might want to display five records per row. Alternatively, you might not want to have the data displayed in a
<table> tag at all, but rather have each element displayed in a
The DataList abandons the “column” notion adopted by the DataGrid. Instead, the DataList’s display is defined via templates. With a template, the developer can specify both a mix of HTML syntax and databinding syntax. The HTML syntax is regular HTML markup; databinding syntax is delimited by the
<%# and %> tags, and is used to emit contents from the
DataSource record used in constructing a given DataList item. For example, the following ItemTemplate will display the
<asp:DataList runat="server" id="myDataList">
<%# DataBinder.Eval(Container.DataItem, "CompanyName") %>
In addition to the databinding syntax, the template may contain HTML markup. By updating the above template, we can have it so that the
CompanyName field is displayed in a bold font, while the
ContactName field is displayed beneath the
CompanyName field in a non-bold font:
<asp:DataList runat="server" id="myDataList">
<b><%# DataBinder.Eval(Container.DataItem, "CompanyName") %></b>
<%# DataBinder.Eval(Container.DataItem, "ContactName") %>
For each record in the DataList’s DataSource, the ItemTemplate’s databinding syntax is evaluated. The output of the databinding syntax, in addition with the HTML markup, specifies the HTML that is rendered for the DataList item. Along with the ItemTemplate the DataList supports six other templates for a total of seven:
Note that the DataGrid’s TemplateColumn only supports four templates: ItemTemplate, HeaderTemplate, FooterTemplate and EditItemTemplate.
By default, the DataList displays each item as a row in an HTML
<table>. However, by setting the
RepeatColumns property, you can specify how many DataList items should appear per table row. In addition to being able to specify how many DataList items to show per row of the HTML <table>, you can also specify that the contents of the DataList should be displayed using
<span> tags instead of a
<table> tag. The DataList’s RepeatLayout property, which can be set to either Table or Flow, dictates whether the data in the DataList is rendered in an HTML
<table> or in
With its templates and
RepeatLayout properties, it’s obvious that the DataList allows for much more customization of the rendered HTML markup than the DataGrid. This increased customization can lead to more user-friendly displays of data with the DataList, as the DataGrid’s “single HTML
<table> with one table row per
DataSource record” model might not always be the best fit for presenting information. However, to ascertain the usability of the DataList it is not sufficient just to examine the customization improvements over the DataGrid; we must also compare the DataGrid’s sorting, paging, and editing functionality to the DataList’s.
With its EditItemIndex template and EditCommand, UpdateCommand, and CancelCommand events, the DataList can support inline editing. However, adding such functionality with the DataList takes more development time than with the DataGrid. This disparity in development time is due to two reasons:
While inline editing with the DataList is not terribly difficult, the same cannot be said for sorting and paging of the DataList’s data. While such functionality is most definitely possible with some clever programming, adding such functionality to a DataList would take significant development time. Therefore, if it is a requisite that the end-user can sort and page the data, it is likely best to choose the DataGrid over the DataList.
The performance of the DataList is better than that of the DataGrid, most noticeably so when the DataList is in a Web form. Figure 2 shows the results of the Web Application Stress Tool test on the DataList.
Figure 2: Requests Per Second for the DataList
As the results in Figure 2 show, the DataList outperforms the DataGrid most noticeably when the Web controls are placed within a Web form (thereby causing the Web control to emit its ViewState).
Digging Into the Repeater
The Repeater Web control offers the most flexibility in the rendered HTML of all three data Web controls. Unlike the DataGrid or DataList, both of which automatically encase its developer-specified content within predetermined HTML markup, when rendered the Repeater emits strictly the HTML markup you specify. For this reason, if you wish to display data in some way other than in an HTML
<table> or in a series of
<span> tags, you must use the Repeater control.
When using the Repeater, like with the DataList, you specify the markup using templates. The Repeater contains the following five templates:
The HeaderTemplate and FooterTemplate specify the HTML markup to appear before and after the data being bound to the Repeater. The AlternatingItemTemplate and ItemTemplate specify the HTML markup and databinding syntax used to render each record of the Repeater’s
DataSource. For example, imagine that you were binding a DataSet containing employee information to the Repeater, and that one of the fields in the DataSet was
EmployeeName. If you wanted to display a list of employees on a Web page in an unordered list, you could use the following Repeater syntax:
<asp:Repeater runat="server" id="rptEmployees">
<li><%# DataBinder.Eval(Container.DataItem, "EmployeeName") %></li>
The Repeater class is not derived from the
WebControl class, like the DataGrid and DataList. Therefore, the Repeater lacks the stylistic properties common to both the DataGrid and DataList. What this boils down to is that if you want to format the data displayed in the Repeater, you must do so in the HTML markup. For example, in our example above, if we wanted to display the employee names in a bold font we’d have to alter the ItemTemplate to include an HTML bold tag, like so:
<li><b><%# DataBinder.Eval(Container.DataItem, "EmployeeName")
Whereas with the DataGrid or DataList, we could have made the text appear in a bold font by setting the control’s
ItemStyle-Font-Bold property to True.
The Repeater’s lack of stylistic properties can drastically add to the development time metric. For example, imagine that you decide to use the Repeater to display data that needs to be bold, centered, and displayed in a particular font-face with a particular background color. While all this can be specified using a few HTML tags, these tags will quickly clutter the Repeater’s templates. Such clutter makes it much harder to change the look at a later date, especially for others working on the project who have to wade through the mess of HTML syntax. Compare this to specifying the formatting for a DataGrid or DataList. With either of these two controls, you can leave the templates clutter-free by specifying the DataGrid or DataList’s stylistic properties. Additionally, the stylistic properties of the DataGrid and DataList can be set automatically with tools like Microsoft Visual Studio .NET or the ASP.NET Web Matrix.
Along with its increased development time, the Repeater also lacks any built-in functionality to assist in supporting paging, editing, or editing of data. Due to this lack of feature-support, the Repeater scores poorly on the usability scale. Of course, if all you are interested in is displaying data without any fancy bells or whistles, the Repeater’s lack of features in not a major detractor. I stress the word “if” because typically once a Web application is deployed users find that they want additional features, such as sorting, paging, and editing.
The Repeaters one redeeming quality is-not surprisingly-its performance. The Repeater’s performance is slightly better than that of the DataList’s, and is more noticeably better than that of the DataGrid’s. Figure 3 shows the number of requests per second the Repeater could handle versus the DataGrid and DataList.
Figure 3: Requests per Second for the Repeater
When displaying data in an ASP.NET Web page, many Web developers choose the data Web control they are most familiar with, which is typically the DataGrid. However, such blind decisions are not wise as there is no universally “best” data Web control. Rather, when deciding what data Web control to use for a given Web page, ask yourself a variety of questions to determine which control is best suited for the task at hand. Do you want to allow the user to sort through the data? Does the data need to be presented in a format other than an HTML