As we are seeing more and more developers who use their MVC widgets in Sitefinity, we spent some time to make their life easier for the 6.2 release. A lot of issues reported in the past have been fixed, and we have also introduced support for some new functionality requested by developers. This blog post provides the highlights.
Decouple action names from method names
In 80% of the controllers, the name of an action is the same as the name of the method representing this action. However, there are cases where these may be different. For whatever reason, developers may want their method to respond to an action, whose name is different. Phil Haack, who worked on the ASP.NET MVC framework at Microsoft, described what makes a normal method to be an action in a blog post a while ago: How a method becomes an action
To respect the behavior in that blog post, from 6.2 on Sitefinity now supports the ActionName attribute. You can decorate your method with it, and it will respond to an action with the custom name you choose.
Once you change the name of the action using this attribute, all conventions will be based on this new name. If you are already using views, you should rename their files to the new name, unless you refer to them specifically.
Support for HandleUnknownAction
In a common MVC scenario, the requested URL contains information about the controller and action. The routing mechanism executes your controller and calls the method for the action in the URL. What happens if the controller does not implement such an action? In normal ASP.NET MVC, you would get a 404 Not Found response. In Sitefinity, nothing happens (an empty response).
The reason that Sitefinity behaves differently is that it can handle multiple controllers on a single page. If one of the controllers on that page cannot handle the action, the others should be given a chance. The page cannot return a 404 only because a small portion of it cannot handle the request.
This behavior leads to some weird situations when there are multiple controllers on the same page. Switching into detail mode for one of them (adding an item to the URL), makes the other control disappear (because it thinks of the new URL as an action it doesn’t support). Previously, developers had no control over these scenarios.
Sitefinity 6.2 introduces a hook which lets them implement “default” behavior in their controllers. You can override the HandleUnknownAction method in your controller.
This method will be called every time that your controller doesn't implement the action requested in the URL. You can execute a view which shows the default state of the controller (maybe the master view in a master-detail scenario). Note that this is not a normal action method and it doesn't have a return type. You need to call ExecuteResult() on a view if you want to display it.
Support for unobtrusive client validation
One of the features commonly used with MVC is the handling of custom input forms. And one of the features commonly used with input forms is validation. In the WebForms model, developers had a limitation of only using one <form> tag per page. Because Sitefinity combines the WebForms model with the MVC model in its Hybrid mode, this limitation was still there, and it created problems for validation. Sitefinity used custom script for submitting the form, but this custom execution did not fire validation logic. This has been reworked in 6.2.
Now you can use client validation in Hybrid mode without worries. Sitefinity fully supports the unobtrusive client validation approach based on the jQuery validation plugin. You can decorate your model classes with some attributes and based on those, attributes are also added to the generated HTML for the form fields. The jQuery validation plugin uses those HTML attributes to check the specific requirements for each field, and prevents submission of the form if the values are not valid. For more information on using unobtrusive client validation with MVC, please refer to the following article: Unobtrusive client validation
The features described above were requested by the Sitefinity developer community in the months before the 6.2 release. We continue to listen to your suggestions. If you have requests for anything else in our MVC support, please get in touch.