Programming Microsoft ASP.NET 4 - Dino Esposito [227]
The control will then automatically generate an HTML table column for each property available in the bound data source. This is only the simplest scenario, however. If needed, you can specify which columns should be displayed and style them at will.
View Controls
The internal architecture of data-bound controls has changed quite a bit over the years. The first version of ASP.NET came with Repeater, DataList, and DataGrid controls. They were fully integrated in the page life cycle, capable of raising postback events and able to render data according to different types of layouts and algorithms.
In successive versions of ASP.NET, the range of data-bound controls extended to include FormView and DetailsView, which were providing loudly demanded tools for displaying and editing a single record of data. These controls, however, were based on a revised internal architecture that made them capable of handling (not just raising) specific postback events. This was a big change. Along with FormView and DetailsView, Microsoft also introduced the GridView control—a revamped data grid control based on the same architecture of other view controls. Finally, in ASP.NET 3.5 Microsoft also made available the ListView control, which probably is the only view control you would ever want to use. The ListView control sums up the characteristics of all the others, and by properly programming it you can obtain data-driven interfaces of any kind.
Let’s briefly review the characteristics of these controls, reserving a deeper look at GridView and ListView for later in the chapter.
The DetailsView Control
The DetailsView is a control that renders a single record of data at a time from its associated data source, optionally providing paging buttons to navigate between records. It is similar to the Form View of a Microsoft Access database and is typically used for updating and inserting records in a master/detail scenario.
The DetailsView control binds to any data source control and executes its set of data operations. It can page, update, insert, and delete data items in the underlying data source as long as the data source supports these operations. In most cases, no code is required to set up any of these operations. You can customize the user interface of the DetailsView control by choosing the most appropriate combination of data fields and styles from within Visual Studio. You do not have much control over its markup, however.
Finally, note that although the DetailsView is commonly used as an update and insert interface, it does not natively perform any input validation against the data source schema, nor does it provide any schematized user interface such as foreign key field drop-down lists or made-to-measure edit templates for particular types of data.
The FormView Control
FormView can be considered the templated version of the DetailsView. It renders one record at a time, picked from the associated data source and, optionally, provides paging buttons to navigate between records. Unlike the DetailsView control, FormView doesn’t use any internal generation of markup and requires the programmer to define the rendering of each item by using templates. The FormView can support any basic operation its data source provides.
Note that the FormView requires you to define everything through templates, not just the things you want to change. The FormView has no built-in rendering engine and is limited to printing out the user-defined templates.
In ASP.NET 4, the FormView control offers a new property—the RenderOuterTable Boolean property—through which you can skip the usual