Rod
Rod

Reputation: 15423

objectdatasource cast gridview datasource back to generic list

Environment: asp.net fx3.5

I'm using the objectdatasource for my gridview. At first, I load up my gridview with records from a generic List<Attachments> for my customer. Next I'd like to add/remove items from the gridview without hitting database until after all the add/removes are done. Then the user will hit Save button and then I will persist the items in the gridview.

My question is how do I add/remove items in the gridview while the objectdatasource is wired up to gridview? My guess is somehow cast the gridview rows back to generic list, and add/remove items, and rebind? Is that even possible?

Upvotes: 0

Views: 806

Answers (3)

deostroll
deostroll

Reputation: 11975

You can temporarily store in the ViewState. You'll need to have a provider class, i.e. a class which does the basic CRUD operations to the list you are storing in the viewstate.

Upvotes: 1

Adil
Adil

Reputation: 148110

I would recommend to save changes to database if you are doing or can do postback on add/remove. As not saving data along change might cause loss of information. You can use ajax call for add/remove to make it more elegant and fast without reloading whole page.

or

If you want to do all add/remove on client side and finally saving to database, you can uses client storage to keep the changes temporarily and finally sending the changes back to server and commit them to database. Article about client storage here but it might not be supported by old browsers

or

You can put change in hidden fields e.g for deleted records you have one hidden field which store deleted record ids, on hidden field with added records with set pattern and update the database on postback using these hidden fields again there is hazard for losing information with this method

Upvotes: 1

Limey
Limey

Reputation: 2772

Since you will just be using the grid events to store all this information off for processing, the only thing you would need in your datasource is a select method, that way it won't try to update/Insert the records. You can do all your event handling on the rowCommand event.

As for what you are trying, I don't think its a good idea. You will have to track multiple records in your session, or a seperate DB table (but then what would be the point?).

Upvotes: 0

Related Questions