I'm unable to delete rows client-side using 2013.2. Among other things, I've tried the
grid.get_rows().remove(row) and it leaves the row as it is and visible. This is despite have editing core behavior added, and I even tried adding the delete behavior. I have batching turned on since I don't want postbacks/rebinding on every action. I had to fall back to how some posts in the forums suggested, by hiding the row with
$(row.get_element()).css('display', 'none')
This hides the row, but the alternating grid row colors now don't alternate since the grid counts that invisible row.
rebones,
Have you tried the suggestion in this post (http://ko.infragistics.com/community/forums/t/73137.aspx) : grid.get_behaviors().get_editingCore().undoBatchUpdate(row); ?
That's where I got the idea to hide the row. Unfortunately that doesn't remove the row. It seems to just undo an add operation if you weren't bound on the server.
I populate my grid with results 1-5, render it to the user. The user may want to delete #3 and add #6. I don't want a postback for every operation since this grid is only displaying a subset of data for the entire page's data. I only want a postback when the user clicks Save and I can handle all my CRUD operations in a Save method.
What was suggested (and I tried it anyway despite it being unintuitive), would seem to only affect rows that got added under the conditions described in that thread and doesn't allow you to delete a row in the grid that was populated on the server. Despite that, I gave it a try and as I mentioned in my reply, it does not work.
Hi revbones,
The undo method is not going to be appropriate for this scenario. For a row that is marked for deletion by BatchUpdate, there are two options.
The first is not to hide the row, and allow it to be visible with your batch-of-updates. This will keep the Alternate Row Styles for every other row, including the rows that are in the batch for an update. When the user the user clicks 'Save' and sends the updates for the CRUD operations, the alternate row styling will refresh for the rows of the grid.
The second option is to commit your deletes so they are totally removed from the grid. Though calling commit() will trigger a post-back, sending all updates to the server.
These are the only two options. 'Hiding' a row marked for deletion does not delete the row, and as such the row, even though 'hidden', remains in HTML and is therefore seen to exist by the Alternate Row Styling.
Let me know if you need any additional assistance regarding this.
Unfortunately neither of the two suggestions works for me. I realize that the WebDataGrid is hamstrung by the architecture requiring either commits with a postback for every single action or BatchUpdates that apparently only have a limited subset of what would be expected functionality.
I have written wrappers to extend the functionality of the grid at this point to track row level changes, to actually hide deleted rows, and to restyle the alternating row styling/striping. It's unfortunate that I had to do so, as this functionality really should have been backed in by this point. It was for years with the UltraWebGrid, and now several years after that was replaced by the WebDataGrid, the functionality is still lacking.