Comments on: Where is the Row in RowCommand? DisplayIndex http://mhinze.com/archive/where-is-the-row-in-rowcommand/ this is an archive of the old blog, ended 6/16/08 Wed, 03 Dec 2008 03:24:47 +0000 http://wordpress.org/?v=2.5.1 By: Rob Kent http://mhinze.com/archive/where-is-the-row-in-rowcommand/#comment-5378 Rob Kent Mon, 25 Jun 2007 09:29:51 +0000 http://mhinze.com/where-is-the-row-in-rowcommand/#comment-5378 Datakeys depends on ViewState, as I discovered with much pain on a previous application. I tend not to use ViewState if I can avoid it because I don't like that much data being transported in the HTML. However, that means you must rebind your grid during Init in order to fire the command events. This in turn means that you must have a persistent store for your original datasource and the list contents must not change since the previous bind, otherwise row 'n' may no longer be row 'n' and you end up performing the action against the wrong PK row. The above problem happened on an auction site I was working on in which I had to make sure the list contents were always bang up to date. The list I bound to had changed and I selected the wrong row (during testing, I hasten to add). This problem is exacerbated if you use an ObjectDataSource against a business facade, because the ODS will fetch the data from the data tier when it wants to. Even if you turn on caching to avoid this, it is not optimal because it uses application cache, so expiring the key applies to all users. I ended up overriding the ODS cache with my own in session and setting a flag when I wanted it to refresh for the db, normally when the user sorted or paged. Also the ODS does not work if you are using sorting, so is completely useless IMHO. After looking in depth at all this, I think that the concept behind the server-side event structure is wrong somehow, in that you should be able to fire row or command events without using viewstate or rebinding - which are both inefficient. Even without using Javascript and the explicit Viewstate object, it would have been better to have some PK collection implemented in a hidden form field and properly wire up each control to reference that, so that you could post back and fire an event whose argument was always your PK, or a pseudo-PK of the row index if you didn't provide one. I tend to use different approaches dependent on the needs of the grid. Typically, I avoid ODS, turn off Viewstate, use templated fields with the PK argument, and store the list source in Session. However, I don't like this at all and think MS should redesign databinding and event firing for listbound controls. Datakeys depends on ViewState, as I discovered with much pain on a previous application. I tend not to use ViewState if I can avoid it because I don't like that much data being transported in the HTML.

However, that means you must rebind your grid during Init in order to fire the command events. This in turn means that you must have a persistent store for your original datasource and the list contents must not change since the previous bind, otherwise row 'n' may no longer be row 'n' and you end up performing the action against the wrong PK row.

The above problem happened on an auction site I was working on in which I had to make sure the list contents were always bang up to date. The list I bound to had changed and I selected the wrong row (during testing, I hasten to add).

This problem is exacerbated if you use an ObjectDataSource against a business facade, because the ODS will fetch the data from the data tier when it wants to. Even if you turn on caching to avoid this, it is not optimal because it uses application cache, so expiring the key applies to all users. I ended up overriding the ODS cache with my own in session and setting a flag when I wanted it to refresh for the db, normally when the user sorted or paged. Also the ODS does not work if you are using sorting, so is completely useless IMHO.

After looking in depth at all this, I think that the concept behind the server-side event structure is wrong somehow, in that you should be able to fire row or command events without using viewstate or rebinding - which are both inefficient.

Even without using Javascript and the explicit Viewstate object, it would have been better to have some PK collection implemented in a hidden form field and properly wire up each control to reference that, so that you could post back and fire an event whose argument was always your PK, or a pseudo-PK of the row index if you didn't provide one.

I tend to use different approaches dependent on the needs of the grid. Typically, I avoid ODS, turn off Viewstate, use templated fields with the PK argument, and store the list source in Session. However, I don't like this at all and think MS should redesign databinding and event firing for listbound controls.

]]> By: Rick Strahl http://mhinze.com/archive/where-is-the-row-in-rowcommand/#comment-3729 Rick Strahl Mon, 11 Jun 2007 03:44:24 +0000 http://mhinze.com/where-is-the-row-in-rowcommand/#comment-3729 Ah - one more way to do this :-}. But that was part of my point - there are so many different ways to get at these values and none of them are easily discoverable nor obvious in how you hook them up. In fact I didn't even know that you can use the datakeys this way (apparently I don't use the grid often enough)... It sure would be much easier if the selected DataItem came back directly in which case we'd have access to the underlying data directly. Ah - one more way to do this :-}.

But that was part of my point - there are so many different ways to get at these values and none of them are easily discoverable nor obvious in how you hook them up. In fact I didn't even know that you can use the datakeys this way (apparently I don't use the grid often enough)…

It sure would be much easier if the selected DataItem came back directly in which case we'd have access to the underlying data directly.

]]>