The ASP.NET DataGrid control provides a built-in engine for paging through bound data. The engine supports two working modesautomatic and manual. Automatic paging means that you bind the whole data source to the control and let it go. The control displays a proper navigation bar and handles users clicking on the movement buttons. Automatic paging doesnt require a deep understanding of the grids internals, nor does it take you much time to arrange an effective solution. For large data sets, though, it might not be a smart option. Handcrafted, custom paging is the alternative. (Note that custom paging has been the usual technique that many applications implemented for yearsjust downloading all and only the records needed for display.)
Custom paging means that the host page is responsible for filling the grid control with up-to-date information. When the grids current page index is, say, 3 the page must provide the set of records that fit in page number 3. The amount of data moved from the database (or any level of caching) to the binding context of the control is minimal. More importantly, the page author gains total control of the grids displayed content.
Paging normally consists of a fixed page size and a variable number of pages. As you probably already know, this is merely one of the possible perspectives of data display. Paging implies showing data that has been grouped in some way. Can you honestly say that showing orders by year, or customers by initials, is really different from paging? In ASP.NET, little changes to the built-in paging mechanism can provide just this functionality. Lets see how.
The first step entails enabling custom paging on the DataGrid control. You do this by setting the AllowCustomPaging property to True. Note that the property is effective only if AllowPaging is also True. As the second step, you define the virtual size of the data source being paged. The VirtualItemCount property indicates the expected number of records through which the grid is called to page. Although the displayed pages will actually show a variable number of records, a maximum page size must be set. Lets say this is 100. The number is merely an upper bound and doesnt affect the performance of the grid. The only drawback is that Visual Studio .NET will display a very long grid at design time. The ideal value of VirtualItemCount is the maximum page size by the expected number of pagessay, 12 if you page per month.
Next, you arrange a page method, or a custom class, to provide the data. The data source provider will take month and year and prepare an ad-hoc query. What will the pager bar look like? The pager must be configured to show page numbers and appears as a list of progressive indexes. Whenever you change page, the CurrentPageIndex property is updated and fresh data is bound. You have two open points left. First, how would you turn page indexes in months or any other information you use to display on the pager bar? Second, how would you update the pager bar to show month names instead of numbers? The second point is easier; write a handler for the ItemCreated event and modify the layout of the pager on the fly. The page index is a 0-based value that indicates the position of the clicked page. You write a custom function that takes this value as input and returns information needed for the query. For example, the page index is a 0-based index whereas the months index is a 1-based number. Heres the code you need in this simple case.
int monthIndex = grid.CurrentPageIndex + 1;
What if you want to group customers by initials? You create an array of strings and use the page index as a selector within the array.
Judging from the final result, you have everything but a grid; looking at the internals, you simply have a customized DataGrid control.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at firstname.lastname@example.org.