Server-side ASP.NET Data Binding, Part 3: Interactive DataGrids

In the previous two parts of this series on data binding, I investi-gated various ways to customize the GUI of the DataGrid control-certainly the most versatile of all the new ASP.NET data-bound server-side controls. This month, I'll dig into the possibilities that the DataGrid offers for adding more interactivity to the user interface. This feature comes at the price of automatic and hidden round-trips, which the ASP.NET postback event engine manages for you.

For a DataGrid component, interactivity usually means the ability to select one or more rows, edit, and apply the changes to whatever storage device is in use. Unless you're going to use custom ActiveX controls or Java-language applets, DHTML is an absolute must. Of course, using DHTML reduces the size of the potential audience somewhat. Selection and in-place editing, when accomplished using plain old HTML and script, requires that the page be refreshed to reflect edits and updates.

The typical workaround is to deliver two versions of the application. One version is targeted at Microsoft Internet Explorer 4.0 and higher using the power of DHTML and scriptlets. The other is targeted at HTML 3.2-compliant browsers and is based on a mechanism that detects the click on a table row (a

tag), then moves to another page. This page, in turn, displays the selected row in a different color or provides a form whose input fields have already been initialized with the various cell values-the tags. Keep in mind this is a simple but effective schema because it closely maps to what ASP.NET does with significant help from the postback events mechanism.

In this column, I'll first provide the solution using scriptlets and Internet Explorer behaviors. Next, I'll move to ASP.NET and review the DataGrid capabilities for selection and in-place editing.the DataGrid capabilities for selection and in-place editing.

DHTML Interactive Grids

DHTML lets you easily modify your page layout to reflect interactive events such as selection and editing. Once you have a table of records displayed, selection is as easy as tracking down the index of the currently selected row and modifying its style after a click event, as you'll see in the following code:

SAMPLE ONE: (below)

The previous snippet comes from the demo scriptlet you'll find in this month's source code (see the link at the top of this article).
Basically, this code intercepts any click on any table row. (All rows in the table have been given the same ID-namely, tableRow.) When there is a click event, the script runs and it calls into the SelectRow function, which simply modifies some CSS styles to reflect the new state. A global variable called m_selectedRow holds the currently selected row as a DHTML object. Within the body of SelectRow, the first action taken is to deselect the current row. This is accomplished by changing the name of the CSS class associated with the underlying tag. Next, the variable is updated to contain the newly selected row, whose style is changed to that of a selected item.

This code is pretty simple, yet it requires DHTML or at least special browser support for dynamic changes to CSS styles. The script code you need is plain client-side script that I've embedded in a scriptlet for better reusability. To read the content of the clicked row, use the innerHTML property of the object it represents:

SAMPLE TWO:(below)

So much for selection in a table. Editing, though, is a different story. First of all, you must figure out a way to prompt the user with the current content of the row. Next, you must give them a chance to modify it and store all the changes. No matter which technique you use to bring the content of the table to the client (XML data islands, hidden fields, hidden elements), you will most likely need to go to the server to finalize any editing that the user performed. The only exception to this is when you're using client-side persistence through COM objects or the Internet Explorer 5.0 persistence behavior. However, this is almost never the case on the Internet.

In creating interactive DHTML grids, you can design a compelling user interface with dialog boxes that pop up or unroll from the edges, but while they may look slick, they still require round-trips to the server. Figure 1 shows the scriptlet in action.



Figure 1 The Scriptlet in Action

ASP.NET has been specifically designed to make the interaction between users and pages easy to code and portable across browsers. If you don't use DHTML, more round-trips to the server will be necessary for updating pages. The DataGrid server-side control and the column templates I explored last month have much more to offer-in particular, the selectable style and edit template for rows.

Selecting Items in DataGrid

As explained earlier, a selected item is just an ordinary item rendered with a different style or layout. To enable item selection in a DataGrid, you must provide two parameters: the action that fires the selection process and the new style for a selected element. In turn, the DataGrid raises a specific event, SelectedIndexChanged, whenever the selected item changes.

As you know, a user selects items by clicking them. Normally, they're allowed to click anywhere on the row of interest. However, the DataGrid control also gives you a chance to narrow the area that can be clicked to select a row. For example, you could add a new column to the table whose only purpose is selecting the parent row.

SAMPLE THREE: (below)

TO SEE COMPLETE ARTICLE:
http://msdn.microsoft.com/code/default.asp?URL=/code/sample.asp? url=/MSDN-FILES/026/002/294/msdncompositedoc.xml