Programming Microsoft ASP.NET 4 - Dino Esposito [237]
Figure 10-8. Image fields in a GridView control.
Templated Fields
Figure 10-9 shows a customized column where the values of several fields are combined. This is exactly what you can get by using templates. A TemplateField column gives each row in the grid a personalized user interface that is completely defined by the page developer. You can define templates for various rendering stages, including the default view, in-place editing, the header, and the footer. The supported templates are listed in Table 10-13.
Table 10-13. Supported Templates
Template
Description
AlternatingItemTemplate
Defines the contents and appearance of alternating rows. If these items are not specified, ItemTemplate is used.
EditItemTemplate
Defines the contents and appearance of the row currently being edited.
This template should contain input fields and possibly validators.
FooterTemplate
Defines the contents and appearance of the row’s footer.
HeaderTemplate
Defines the contents and appearance of the row’s header.
ItemTemplate
Defines the default contents and appearance of the rows.
A templated view can contain anything that makes sense to the application you’re building—server controls, literals, and data-bound expressions. Data-bound expressions allow you to insert values contained in the current data row. You can use as many fields as needed in a template. Notice, though, that not all templates support data-bound expressions. The header and footer templates are not data-bound, and any attempt to use expressions will result in an exception.
The following code shows how to define the item template for a product column. The column displays on two lines and includes the name of the product and some information about the packaging.
<%# Eval("productname")%> available in <%# Eval("quantityperunit")%>
Figure 10-9 demonstrates template fields in action.
Figure 10-9. Template fields in a GridView control.
Working with the GridView
A big difference between the old-fashioned DataGrid control and the GridView control is in how the control interacts with the host page. The interaction that is established between the DataGrid and the host page is limited to exchanging notifications in the form of postback events. The DataGrid lets the page know that something happened and leaves the page free to react as appropriate. The GridView, instead, if bound to a data source component can resolve postbacks on its own by interacting autonomously with the bound component. For both DataGrid and GridView controls, however, the main operations are paging, sorting, and in-place editing.
Paging Data
The ability to scroll a potentially large set of data is an important but challenging feature for modern, distributed applications. An effective paging mechanism allows customers to interact with a database without holding resources. To enable paging on a GridView control, all you do is set the AllowPaging property to true. When the AllowPaging property is set to true, the grid displays a pager bar and prepares to detect a user’s pager button clicks.
When a user clicks to see a new page, the page posts back, but the GridView traps the event and handles it internally. With the GridView, there’s no need to write a handler for the PageIndexChanged event. The event is still exposed (and partnered with PageIndexChanging), but you should handle it only to perform extra actions. The GridView knows how to retrieve and display the requested new page. Let’s take a look at the following control declaration:
Any data the data source component binds to the grid is immediately pageable. As shown