Programming Microsoft ASP.NET 4 - Dino Esposito [251]
Note
The ItemCommand event fires only if the original click event is not handled by a predefined method. This typically occurs if you define custom buttons in one of the templates. You do not need to handle this event to intercept any clicking on the Edit or Insert button.
Compared to Other View Controls
The view controls introduced with previous versions of ASP.NET solved many problems that developers were facing every day. Controls such as GridView and DetailsView make it a snap to create a list of records and even arrange a master/detail view. However, they offer limited control over the actual markup generated. Want an example? With a GridView control, placing a TBODY tag around the group of child rows is not a trivial task. And it is almost impossible to do with a DataGrid control, unless you resort to your most advanced skills and take on the tough task of deriving a custom grid control.
On the other hand, adapting the final markup to the actual needs would be quite a simple task if the view controls introduced with earlier versions of ASP.NET provided a bit more programmatic control over the rendering process and templating. This is just one of the key capabilities you gain with the ListView control. As you’ll see in a moment, the ListView control is flexible enough to render out in a tabular or tiled manner. It can be used to replace the GridView control, at least in relatively common situations, but also to create completely custom layouts.
This said, let’s briefly compare the ListView control to the other view controls available in ASP.NET to see exactly what each control can do and cannot do. Table 11-4 lists and briefly describes the view controls.
Table 11-4. Rich, Data-Bound View Controls in ASP.NET
Control
Description
DetailsView
Designed to represent a single record of data, the control renders out a tabular and fixed layout. You decide the fields to be rendered and their format. You can use templates to customize the appearance of individual data fields, but you can’t change the overall table-based layout. The control supports in-place editing as well as insertion and deletion, and it goes down to the bound data source control for the actual data access tasks. As long as the underlying data source supports paging and sorting, the control makes these functionalities available through its own user interface.
FormView
The FormView control can be considered to be the fully templated version of the DetailsView control. It renders one record at a time, picked from the associated data source and, optionally, supplies paging buttons to navigate between records. It doesn’t provide any free user interface. You have to build all of it using header, item, and footer templates. FormView doesn’t use data control fields and requires the user to define the rendering of each item by using templates. It supports any basic data access operation its data source supports, but you have to provide ad hoc trigger buttons.
GridView
The GridView control provides a tabular, grid-like view of the contents of a data source. Each column represents a data source field, and each row represents a record. You can use templates to customize individual data fields, but you are forced to use the tabular representation of contents. The granularity of customizable items is the table cell. With some hard work, though, you can change the structure of the table row—for example, you can add or remove cells. You can hardly do more than this, however. Like other view controls, the GridView also fully supports two-way data binding.
So where does the ListView control fit in this puzzle of data-bound controls? Like all the controls listed in Table 11-4, the ListView control supports two-way data binding—that is, the ability of displaying and editing the contents of the bound data source. Unlike the others, though, the ListView