Working with the ListView
The ListView is the most powerful of the DataView controls and the hardest to work with. Here's how to minimize the pain while getting all the benefits.
It's no secret that I'm a very big fan of visual designers which is probably why I don't use the ListView control enough: No visual designer. That's too bad because the ListView is, without a doubt, the most powerful control in the Data section of the toolbox. While the GridView lets you display multiple rows at once and the FormView gives you control over the display format, only the ListView lets you do both: Display multiple rows at the same time using any format you want.
When you drag a ListView onto the page you get a gray box in design view. The first step in setting it up is to configure a DataSource and link the DataSource to the ListView. You still get a gray box. To actually get something to display you have to pick Configure ListView from the ListView's SmartTag. In the resulting dialog you can select a layout, a style, and whether or not to turn on paging (if you turn on paging you get a choice between two different paging styles). These choices will generate some default templates for your ListView and is infinitely preferable to creating them yourself.
Once you get the templates generated, you'll actually get a display that shows something: What the control will look like (sort of) when initially displayed in the browser -- it's called the "Runtime View." You won't get a visual designer for adding and removing controls from the ListView's templates as you would with, for instance, the FormView or templated columns in the GridView. Actually, that's not strictly true: You do get a visual designer for the empty template. For any template that displays data, though, you'll need to go into Source View.
In Source View you'll find a set of templates with some very old school tables inserted and controls inside the cells of the table. Here's a typical ItemTemplate with a set of Label controls bound to properties or fields from the DataSource that this ListView is bound to:
<asp:ListView ID="ListView1" runat="server"
<tr style="background-color:#DCDCDC;color: #000000;">
<asp:Label ID="CustomerIdLabel" runat="server"
Text='<%# Eval("CustomerId") %>' />
<asp:Label ID="CompanyNameLabel" runat="server"
Text='<%# Eval("CompanyName") %>' />
... more templates...
The updateable templates (InsertItemTemplate and EditItemTemplate) vary from the ItemTemplate in two ways: they use updateable controls (e.g. a TextBox instead of a Label) and use the Bind function instead of the Eval function (the Bind function supports two-way databinding). A typical entry in the EditItemTemplate would look like this:
<asp:TextBox ID="ContactNameTextBox" runat="server"
Text='<%# Bind("ContactName") %>' />
You can replace the default controls with your own controls in Source View and you're no way obligated to use tables to lay out your templates. Effectively, you can treat each template as a mini-form that will be repeated for every row you retrieve from your DataSource.
For instance, if you're retrieving a Boolean field you'll want to replace the default TextBox generated with the templates with a more appropriate CheckBox. The resulting tag would look like this but you'll have to type it in yourself:
<asp:CheckBox ID="CompanyActiveCheckBox" runat="server"
Checked='<%# Eval("Active") %>' />
You could, of course, drag in a CheckBox control but, quite frankly, it adds so little text that it's faster just to modify the default tags added for you. Fortunately, adding or replacing controls in the ListView is the most difficult part of using the ListView. No, really.
For instance, adding Validators to the ListView isn't any more difficult in Source View as compared to Design View. You still drag the Validator into the ListView and drop it beside the control you want to validate. And you can still, fortunately, set the properties on the Validator control in the Property window.
I've been ignoring some key issues with the ListView: How to build your headings, turn on editing and using databound controls. I'll look at them in my next column.
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.