Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Not-So-Quick Tour of the Web DataGrid Control : Page 4

The DataGrid control works as a multi-column, fully templated grid of data. It provides a built-in infrastructure for many common tasks including paging, sorting, and editing. To exploit the DataGrid to the fullest, you need to write a relevant quantity of code—mostly handlers for the various events fired during the control's life cycle. Don't be fooled by the fact that you normally write a lot of glue code with data grids. What you get in return for that effort really pays off.


advertisement
Paging the Grid's Contents
In real-world scenarios, the size of the data source easily exceeds the real estate of the page. Many applications use data paging to gain scalability and present a more helpful page to the user. Especially on the Web, displaying only a few rows at a time is a more effective approach than downloading hundreds of records that stay hidden most of the time. The DataGrid control provides some built-in facilities that let the programmer easily switch to a new page according to the user's clicks. The control needs to know how many items to display per page, what type of functionality you require for the pager, and the data source to page through. In return, the control tracks the current page index, extracts the rows that fit into the particular page, and refreshes the user interface. Whenever the page index changes, the control files the PageIndexChanged event to the application.

The DataGrid supports two types of paging—built-in paging and custom paging. Built-in paging assumes that all the records that you scroll through are memory resident. The DataGrid is bound to the source all the time and automatically extracts and displays only the rows that fit on a particular page. Notice that the page's view state does not save the data source; henceforth you must rebind the data source at each postback.

Just because the data source gets lost at each response, caching is vital for effective paging. You download all the data the first time your user access the page, store the data set into the application's Cache object or session memory, and rebind that data to the control until the application or session is over.

In real-world applications, data caching is a double-edged sword. On one hand, it significantly speeds up data retrieval; on the other hand it taxes the Web server's memory and potentially affects the overall scalability of the application. You also need to carefully consider the scope of the data. If all sessions share the data and that data doesn't get stale often, then you can store it once in a global object. If you need to store a distinct copy of the data for each session, then the default built-in paging is probably not the smartest approach you can take. It requires a lot of memory and, even worse, pushes an application architecture that doesn't scale well.

Custom paging is designed to work around the data cashing risks. When you enable custom paging, the DataGrid assumes that you want to display all the records in the data source on the page. In this case, the DataGrid doesn't even attempt to extract a page from the bound data. The application is therefore responsible for ensuring that, at any time, the data source contains only the records for the current page. With custom paging your application downloads a small subset of data from the database at each request. If you opt for built-in paging, the following code snippet summarizes the layout of the page data access layer.

void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { LoadDataFromDatabase(); BindData(); : } : } void LoadDataFromDatabase() { DataTable data = ExecuteQuery(cmdText, connString); Cache["AppData"] = data; } void BindData() { DataTable data = (DataTable) Cache["AppData"]; : grid.DataSource = data; grid.DataBind(); }

The data loads only once and it gets cached in memory. Whenever the page posts back, the application retrieves data from the cache and binds it to the DataGrid control.

To enable paging in a DataGrid control you must set the AllowPaging property to true. When you turn the property on, the control user interface automatically acquires an extra component—the grid pager. The pager is a built-in toolbar with links to move from one page to the next or to previous pages. You normally configure the pager declaratively by specifying the working mode and a few visual settings. The PageSize property lets you control the maximum number of rows that each page should contain. By default, this value is set to 10.

After you turn the pager on, you're only half way there. The pager is displayed and updated, but is not functional until you write and register a handler for the DataGrid's PageIndexChanged event.

<asp:datagrid runat="server" id="grid" : allowpaging="true" onpageindexchanged="PageIndexChanged">

The delegate for the PageIndexChanged event is shown below. It passes down to the handler a data structure of type DataGridPageChangedEventArgs.



public delegate void DataGridPageChangedEventHandler( object source, DataGridPageChangedEventArgs e);

The class inherits from EventArgs and features two extra properties—CommandSource and NewPageIndex. The former represents the source of the event. Since the event only fires when a user clicks a button in the pager, the event source is nothing more than the pager itself—that is, a DataGridItem object. The NewPageIndex property contains the updated index of the page. The DataGrid's internal engine calculates the correct index of the new page based on the button that the user actually clicked. The following code shows the typical (and minimal) page changed handler for a DataGrid control. It sets the grid's CurrentPageIndex property with the new page index and rebinds to the data.

void PageIndexChanged(object sender, DataGridPageChangedEventArgs e) { grid.CurrentPageIndex = e.NewPageIndex; BindData(); }

When the DataGrid's DataBind method executes, the control extracts the subset of rows from the data source that fits onto the current page. The rest of the code in the DataBind method loads those records into the Items collection and uses the records in the collection to generate the HTML output for the control.

The pager component is a table row made of a single cell that spans the whole width of the grid. The DataGrid provides some built-in properties to let you customize the pager bar both declaratively and programmatically. In particular, you can choose between two display modes—numeric pages and next-prev mode.

By default, the pager is made of two link buttons pointing to the previous and the next page respectively. The default text associated with these links is < for the previous button and > for the next button. You can change the text for each link using the PrevPageText and NextPageText properties. The following code demonstrates how to configure the pager using the <pagerstyle> element.

<pagerstyle backcolor="gray" forecolor="white" font-name="webdings" font-size="12pt" prevpagetext="3" nextpagetext="4" />

The font of the pager is set to Webdings. According to this font, the strings 3 and 4 are equivalent to the characters ? and ?.

The DataGrid supports various types of data-bound columns, including text, templated, and command columns.
The display mode of the pager is controlled by the Mode property whose feasible values are NumericPages and NextPrev. The Mode property takes its values from the PagerMode enumeration. The default setting is NextPrev and results in two buttons, one to move to the previous page and one to jump to the next page. The DataGrid control automatically enables and disables the links according to the index of the current page.

When working in numeric pages mode, the pager displays as many links as there are pages in the data source. The PageCount read-only property provides the total number of available pages. Figure 5 provides a side-by-side view of the two interfaces (NumericPages on the left and NextPrev on the right).



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Thanks for your registration, follow us on our social networks to keep up-to-date