I have posted this question in this forum before ( http://forums.asp.net/t/1365376.aspx ), but as I didn't get any replies I am re-wording it to be a bit more provocative (and I may even slightly overuse CAPITAL LETTERS) in the hope of goading people into replying :-)

Please consider the following quotes (I have added the italics to the parts of the quotes that I refer to below). The first is from the author of a book on ASP.NET and the second is from a Microsoft MVP, in other words, both are from EXPERTS:

http://flux88.com/blog/leveraging-existing-asp-net-features-in-asp-net-mvc/
“As you just discovered, some ASP.NET server controls work with ASP.NET MVC, but which ones? How can we tell if a control will work or not? To put it simply, any control that depends on ViewState or generates post-backs will not work. Some controls will render, but they require a <form runat=”server”> which you might not want to add. Adding a server-side form tag will put hidden fields on the page for ViewState and event validation. The form will also POST to the same action you’re on, which is usually unacceptable. … none of the advanced features of the GridView will work. No sorting, paging, editing, or selecting.”

http://weblogs.asp.net/fredriknormen/archive/2007/11/14/asp-net-mvc-framework-an-early-look.aspx
“The MVC Framework doesn’t support postbacks and the use of ViewState, so most of the Controls shipped with ASP.Net can’t be used. Microsoft will probably add new Controls for the MVC Framework. … Two controls that would be hard to live without would be the <asp:TreeView /> and the <asp:Calendar />. The TreeView works fairly well, however it generates post-backs that do nothing. The visual aspect works just fine, however. The calendar relies heavily on post-back for navigation, so unfortunately it does not function in ASP.NET MVC.”

My response is as follows:

1. The statement that “the MVC Framework doesn’t support postbacks and the use of ViewState” is WRONG. Postbacks do still happen and ViewState still exists under MVC (see further details below).

2. The statement “any control that depends on ViewState or generates post-backs will not work” is WRONG. I have tried a list box with AutoPostBack turned on, as well as a TreeView, GridView and Calendar. The post-backs go back to the controller action that created the view, and the controls all work fully as far as I can tell. The calendar works, and I have successfully used sorting and selecting with the grid – why then do the quotes above INCORRECTLY say that the calendar does not work and that advanced features of the grid such as sorting and selecting do not work?

The only problem I have found is if HTMLHelper.RenderPartial() to render a user control. If this is present on a page, any postback gives the error “Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.” See http://asp-net-controls.blogspot.com/2008/11/renderusercontrol-to-renderpartial.html .
 
3. If postback is not meant to be used, then why was the strongly typed version of the “AcceptVerbs” attribute introduced as part of MVC (see http://aspalliance.com/1776_ASPNET_MVC_Beta_Released.7 )? This seems to have been introduced specifically to support postbacks, and is used in examples for this purpose (e.g. http://codebetter.com/blogs/david.hayden/archive/2008/11.aspx , which is an example posted by a Microsoft MVP). Why do these examples and the statements of the experts CONTRADICT one another?

4. If we are not meant to use controls such as the grid, what alternative is there? It seems like a big step backwards to have to hand-code the functionality offered by these controls. Is this what ASP.NET MVC XForms ( see http://www.joncurtis.co.uk/post/ASPNet-MVC-XForms.aspx ) is for?

Ok, I know that maybe the experts aren't WRONG, and maybe I'm MISUNDERSTANDING, and hopefully I've annoyed someone enough that they tell me why I'm wrong :-)

It seems that ANY webcontrol can still be used for rendering purposes. You just have to override the VerifyRenderingInServerForm method of the System.Web.UI.Page object. Turn off the ugly viewstate, and obviously, don't try to wire up any server-side events. I won't necessarily advocate the default webcontrols because of their sometime unpredictable attribute renderings, but I do prefer the structured xml markup of custom server controls vs. writing html helper methods with argument lists. I'll keep an open mind about MVC-style views, but I remain unconvinced so far...which is the beauty of having a choice.

Thanks jrmcoy for your reply. You have said that "it seems that ANY webcontrol can still be used for rendering purposes", but my point is that they actually work for more than just rendering, e.g. I have tested the GridView under ASP.NET MVC and the sorting and selecting work. What I'm wanting to know is why all the explanations I have found on the web say that functionality such as this doesn't work under ASP.NET MVC. Maybe what they mean is that it is not recommended to use this functionality, or that it is against the spirit of MVC, but if that is the case then why don't they say that?

I'm not sure why it is so difficult to get an answer to this question.

I'm not necessarily wanting to use Web Forms controls in this way, I just want to understand the situation, and the information that is out there isn't helping because it contradicts what I have seen in my testing.

 

Quick answer, seems like MVC encourages you to use inline coding and html helpers. I believe the idea is that these views are streamlined, quicker, and require less overhead. Makes sense on the surface, but there are always other factors to consider. For our project, however, we decided to continue using webcontrols for rendering ONLY (long list of reasons). We don't use form elements, viewstate, nor postback. Since MVC is simply built on top of traditional ASP.NET, I'm not surprised webcontrols will still fully work (the postback model isn't that complex when you dig down into it). I guess there's no intentional suppression of that underlying model. The only point of my posting was that if you did choose to use webcontrols AND you didn't use server form controls like us, then you might run into an exception for some webcontrols. The fix is to override the method I mentioned. I would guess that there are probably even developers out there that are rendering their views using XSLT (controller passes model as xml).

I posted my response on my blog: http://flux88.com/blog/leveraging-existing-asp-net-features-in-asp-net-mvc/#comment-5473 Hope this helps. -Ben

Ben, Thanks for your reply - I am much clearer now on what the situation is. Sorry that it has taken me a while to say thanks.