 |
|
^ click above ^ |
05.26.04
 By
Scott
Mitchell
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 <span>
tag.
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 DataSource
field CompanyName:
|
<asp:DataList
runat="server" id="myDataList">
<ItemTemplate>
<%# DataBinder.Eval(Container.DataItem, "CompanyName")
%>
</ItemTemplate>
</asp:DataList>
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">
<ItemTemplate>
<b><%# DataBinder.Eval(Container.DataItem, "CompanyName")
%></b>
<br />
<%# DataBinder.Eval(Container.DataItem, "ContactName")
%>
</ItemTemplate>
</asp:DataList>
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:
AlternatingItemTemplate
EditItemTemplate
FooterTemplate
HeaderTemplate
ItemTemplate
SelectedItemTemplate
SeparatorTemplate
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 <span> tags.
With its templates and RepeatColumns
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:
The Edit/Update/Cancel buttons that can be created in a DataGrid
via the EditCommandColumn column type, must be manually added to
the DataList, and
The DataGrid BoundColumn column types automatically use a TextBox
Web control for the editing interface, whereas with the DataList
you must explicitly specify the editing interface for the item being
edited via the EditItemTemplate.
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:
AlternatingItemTemplate
FooterTemplate
HeaderTemplate
ItemTemplate
SeparatorTemplate
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">
<HeaderTemplate>
<ul>
</HeaderTemplate>
<ItemTemplate>
<li><%# DataBinder.Eval(Container.DataItem, "EmployeeName")
%></li>
</ItemTemplate>
<FooterTemplate>
</ul>
</FooterTemplate>
</asp:Repeater>
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:
<ItemTemplate>
<li><b><%# DataBinder.Eval(Container.DataItem,
"EmployeeName")
%></b></li>
</ItemTemplate>
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.
*This article originally appeared on the ASP.NET
Dev Center at MSDN
Read
the Full Article
About the Author:
Scott
Mitchell, author of five ASP/ASP.NET books and founder of 4GuysFromRolla.com,
has been working with Microsoft Web technologies for the past five
years. An active member in the ASP and ASP.NET community, Scott is
passionate about ASP and ASP.NET and enjoys helping others learn more
about these exciting technologies. For more on the DataGrid, DataList,
and Repeater controls, check out Scott's book ASP.NET Data Web Controls
Kick Start (ISBN: 0672325012). Read his blog at : http://scottonwriting.net
Read this newsletter at:
http://www.webproasp.com/2004/0521.html |
|
| From
the Forum: |
| Chat
Client Recommendations |
I hope this is the right place to post this
one...
Have a site we're going to start development on shortly. One
of the big parts we are working out is do we go with a pre
packaged chat room for the site or do we custom design our
own. I'm leaning towards prepackaged as there's so many and
we'd have to charge a fortune to build one that includes everything.
Basically looking at possibly two public chat rooms maybe
a public and members only, then the ability for the site admins
to private chat with individuals as they like. they would
like to have the smilies and fluff stuff too if possible.
...
|
 |
|
