Displaying conditional data in a column

[BarbraW]

I have a grid that contains a date field column. Depending on some business rules, I need to display one of three dates in that date field.

The grid is bound to a DataSet that I get back from a web service call in the NeedDataSource call. The dataset contains the 3 date fields, along with other relevant data.

Where is the proper place to put the logic to determine which date field to display? I can put it in the NeedDataSource call and do something like dynamically add a new column to the dataset and bind to that column, but I'm wondering if that's the best place to do it. I thought about doing it in the ItemDataBound event, but it doesn't appear that I have access to the non-bound columns in the dataset at that point (do I? how?).

Is there another, better place to do it? It's simple logic, I just need to know the correct place to do it - that is, the most efficient, and one that will not mess up autosorting or filtering - and also have access to the underlying data source and/or columns that I need.

[Todd Anglin]

Hello Barbra-

Usually, any kind of "conditional" display logic that is applied to a row in RadGrid is applied during the OnItemDataBound event. This event fires immediately after the row has been bound to its data and gives you the access you need to modify/update row cells based on your business logic.

That said, the kind of logic we're talking about there is usually "display logic"- such as colors, font weight, etc. It sounds like you may need to conditionally bind cells to a different data field?

If that is the case, things become a bit trickier if you need to support data editing. A grid expects that all values in a column relate to the same data field, and while these values can easily be "overridden" in read-only scenarios, keeping data accurate during editing becomes more challenging. Same is true for filtering and sorting. A single column expects to sort/filter against a single field in the data source.

For situations like this in the past, I've usually had the most success "combining" my similar data values in to a single "view" at the data source level. If you have access to the SQL, this can be done using Views in SQL Server. If you only have access to your service, this can be done in memory by building a new DataTable. By consolidating the data there, then binding it to your RadGrid, all operations like sorting and filtering remain simple.

Does that make sense? Let me know if you have questions with that approach and I'll be happy to elaborate.

-Todd

[BarbraW]

>>Usually, any kind of "conditional" display logic that is applied to a row in RadGrid is applied during the OnItemDataBound event. >>This event fires immediately after the row has been bound to its data and gives you the access you need to modify/update row cells >>based on your business logic.

>>That said, the kind of logic we're talking about there is usually "display logic"- such as colors, font weight, etc. It sounds like you may >>need to conditionally bind cells to a different data field?

Yes, I need to conditionally bind cells to a different data field. As I mentioned, I first looked at doing it in the OnItemDataBound event, but it doesn't look like I have access to the non-bound fields at that point. (is that true?)

I do not need to support data editing. Assume this is a read-only grid.

>>For situations like this in the past, I've usually had the most success "combining" my similar data values in to a single "view" at the >>data source level.

That's the approach I've taken so far - massaging the dataset in the NeedDataSource event before binding it to the grid. I'm just curious if there's a better way.

[Todd Anglin]

I think that approach is the best. The only thing I'd suggest is that you consider moving the "massaging" logic out of OnNeedDataSource in to some "cached" property so that you do not have to massage on every RadGrid data operation.

For example, you can create a private property on your page that returns a DataTable, and in the "getter" for that property, you can perform your massaging once and then "cache" the results to something like the ASP.NET Cache/Session (depending on the scope of the data). That will save you from doing more work than you need to on every paging/filtering/sorting operation.

As for OnItemDataBound, it's actually too late by that point to access your other data fields. That event fires after the cells have been bound, so only data that "matches" a column is available (via the cells directly, not via the data source). You could, of course, access your data source via a property (like above) during the OnItemDataBound event and then execute logic that changes the values of a specific cell, but I think that's less elegant that "cleaning" the data before binding (and probably more CPU intensive).

Sounds like you're on the right track. Hope this input helps. If you get stuck or have trouble, let me know and I'll be happy to assist.

-Todd