As I wrote in a previous post, Microsoft published the Release Candidate 1 of its new ASP.NET MVC framework (extension) last week. Because I am developing an application with ASP.NET MVC since October, I had to migrate from the Beta to the RC1 yesterday. Below you can find some notes about that.
1. filterContext.Cancel
To manage my custom authentication I wrote some custom AuthorizeAttributes and used filterContext.Cancel = true; for denying access to an action. This property has been removed. So it is sufficient to set the Result property to cancel the actual request. Sample:
1: public class AuthorizeGroupCreatorAttribute : AuthorizeAttribute
2: {
3: public override void OnAuthorization(AuthorizationContext filterContext)
4: {
5: // Do some security checks
6: filterContext.Result = filterContext.Controller.GetType()
7: .GetMethod("AccessDenied").Invoke(filterContext.Controller, null)
8: as ActionResult;
9: }
10: }
2. ViewData.Model
It's optional but recommendable to replace your existing ViewData.Model[""] with Model[""].
3. Remove CodeBehind files in your views
Since RC1 there will no CodeBehind files be created when creating a new view, what makes sense when you don't use them (for example for additional databinding of the Repeater control).
For existing views created with an earlier version of ASP.NET MVC you can just delete the two CodeBehind files (*.aspx.cs/*.ascx.cs an *.designer.aspx/*.designer.ascx). To make sure your web compiles after that ;-) you have to fix the header lines of each .ascx and .aspx. Delete the CodeBehind="" attribute and replace the Inherits="" with the following:
- System.Web.Mvc.ViewUserControl for a user control without model
- System.Web.Mvc.ViewUserControl<YourModelType> for a user control with model
- System.Web.Mvc.ViewPage for a view without model
- System.Web.Mvc.ViewPage<YourModelType> for a view with model
4. Remove ViewData["PageTitle"]
In all earlier samples we found some code which demonstrated us how to set the page title to the master page. As many people I didn't think much about that and copied it. But: that's not the best way. Actually only the view should manage the page's title, not the controler. That would not be the final truth in all cases, but in the most. See this blog post to learn more about it (Microsoft changed that in its sample by the way, too).
5. What happened to Html.DropDownList() helper!?
With the beta version I used the automatic databinding of the HTML helper controls, and of course for a drop down list, too. Example:
Controller:
1: ViewData["Status"] = new SelectList(ProfileViewData
2: .GetJobStatusTextDictionary(), "Key", "Value",
3: (int)CurrentApplicant.JobStatus);
View:
1: <%= Html.DropDownList("Status", new { @class = "CssDropdown" })%>
So I had just to deliver a SelectList and all the databinding magic happened within Html.DropDownList(). That might work now as well, but I ran into another problem - this code wasn't executable anymore, because the signature of the DropDownList() method has changed. You can only set HTML attributes as in this sample the CSS class name, if you set a SelectList before.
New and running:
1: <%= Html.DropDownList("Status", new
2: SelectList(ProfileViewData.GetJobStatusTextDictionary(),
3: "Key", "Value", (int)ViewData.Model.JobStatus),
4: new { @class = "CssDropdown" })%>
What at first glance looked like a mistake by refactoring the existing code (as someone has forgotten to test it with htmlAttributes), makes sense at the second look.
It is the same as with the page's title. DataBinding and assigning the data to the helper could (should) propaply be the job of the view only - the controller should not have to know anything about it, it should just delivers the data - that's it. From that point of view it makes sense that you're not using SelectList() within a controller and bind your data within the view.
A bit hard to learn because I had to change more than 10 databinding scenarios, but I am fine with it today ;-).
Summary
As expected there were no breaking changes from the beta version to the first release candidate, but some little changes which were absolutely necessary (in my opinion). ASP.NET MVC looks now very stable and ready for going into production environments all over the world, even if there is a lot to do in the future :-).
