Building Grid in MVC Controller

Question

I have a pattern/design question. Is it considered bad practice to build a grid in the controller of an asp mvc application?

For instance, there are server side adapters for jqgrid in which you can populate a specific model in order to build the grid. This includes constructing the columns, including column options (width, sortindex, exitable, etc).
I typically would look at the construction of the grid as presentation templating / scaffolding that should reside in the view. I would generally prefer to reserve the grid setup code to the view and just have the controller deliver the data to the view. Am I thinking of this in the wrong way?

Thanks for any thoughts.

Answer 1

I agree that the view should manage the presentation concerns, while the controller should handle sending data to the client, processing any business logic, and respond to view events (button click, etc). So I agree the view should render the grid, and the Controller should send the data.

Answer 2

I also agree, the controller should drive the data and the view should drive the display of that data. However, since the controller defines the structure of the data, in a way, it does drive some aspects of the display when it comes to grids. Ideally I wouldn't want to have to change the view and the controller every time I change the underlying model (though sometimes you just have to). I prefer to have a single place that defines the model that the controller can access to structure the data and the view can access to build the grid. Then leave any custom display specifics to the grid definition in the view.

Answer 3

The problem is how deep the elements used in the view need be specified by the view. Just an example. You can use <select> element in the view and it will looks like a little different in different web browsers. The base elements which you could you on the page could be more complex. Just try to use <input type="date"> from HTML5 (see here and try the demo in Google Chrome). You will see many elements of built-in datepicker which you don't explicitly render in your view (by presentation templating).

What I mean is that you can use some controls in the view which you should interpret as base elements which you should don't render. In case of usage jqGrid you should just specify an empty <table> element with an id attribute on the place where you want to have the grid. You will be not explicitly renter the elements of the grid in the view. Instead of that you can fill/set "properties" of the base grid element. The grid will be filled with the data with respect of JavaScript code which you include on the page and the data returned from the corresponding controller action which you should provide for jqGrid.

I agree that such schema matches not ideal with MVC model, but I personally be not for dogmatic following some models.

The only real design problem which I see in described above schema are existing restrictions in defining some parts of the grid colModel mostly in JavaScript code. In case of usage dynamic system it could be more interesting to provide the colModel properties together with the data for the grid. jqGrid don't provide direct way to do this, but I posted some answers which describe how one can do make the corresponding implementation. The main idea consist from the usage setColProp, showCol, hideCol, setCaption, setLabel, setColWidth and other inside of beforeProcessing. It allows to write generic JavaScript code to display any generic grid and to load all properties of the grid from the server. I would recommend you to read the answer which provides some important code fragments and the answer.

Instead of creating the grid with many hidden columns and showing there if required one can use addColumn method with is still in beta phase, but it works good enough, which code I published here (see the corresponding examples in demos subdirectory).