views:

683

answers:

2

The contents of my MVCContrib grid come from the Model on a strongly typed View. When a post is made, the contents of the grid are not in the model object when it returns to the controller. I can see that this is because the grid renders as just a table with text in cells. Is there something I can do so that when the post occurs, the list data I sent down to the grid comes back in the post?

+1  A: 

You can use TempData to persist this information server side. The information in TempData will persist for one request. I do not really like this option however.

Can you not repopulate your model from the db? If the user is not changing the information why do you need to post back all the same unchanged information? Just grab it again from where you got it before.

redsquare
You're right. That is an option. It just seemed to me that I ought to be able to at least get the model back in the state I sent it. But then that's what a form submit is for, and mvccontrib doesn't render "form" controls....
jlembke
A: 

If you want to recreate the model as it was serialised into the grid, you will have to embed correctly named form elements within the grid ( or maybe outside the grid ) and within the same form as the one containing the button that is posting back to the action where you want your Model recreated.

While this is doable, you are essentially recreating __VIEWSTATE, and that defeats much of the joy of working with MVC ( read "it's an ugly hack and you should uninstall your IDE for even thinking it").

It is hard to point you in the right direction without having a better understanding of the scenario you are trying to solve. The usual workflow in these situations is get the model

  1. generate the page
  2. record any changes to the model in a form on the page
  3. submit the changes to an action
  4. get the model again
  5. use TryUpdate to persist the changes from the post into the model

If you are suffering performance issues ( you have proved you've got a perf problem right? You aren't optimising prematurely?), address them where they occur ( i.e. caching in your data access ), rather than bending MVC in ways it really shouldn't be.

Neal