This request is now being tracked on GitHub at https://github.com/aspnet/mvc/issues/727.
It would be helpful if folks could comment on the GitHub issue with specific use cases for when you would want to use an open generic for you view model type. We are trying to get a better feel for the relevant scenarios. Thanks!
We currently support closed generics. Is that sufficient? Or is the request here specifically about open generics?
This is planned for a future version of ASP.NET MVC.
Support for output caching is tracked on our CodePlex site here: https://aspnetwebstack.codeplex.com/workitem/608. Please add your vote to the CodePlex issue if you want this feature!
This won't be in Web API 2.2. We are considered adding this for the next major release of Web API, but this is still under investigation.
In the meantime there are third party implementations that you can look at using:
Moving this back onto our backlog based on customer feedback.
Regarding the comments about client side validation the blog post does have a 2nd part that describes how to setup client side validation: http://blogs.msdn.com/b/stuartleeks/archive/2012/09/07/flexible-conditional-validation-with-asp-net-mvc-adding-client-side-support.aspx.
7 votesSayed Ibrahim Hashimi responded
This item was incorrectly marked as completed previously
This should just work for the Web API project template. Could you walk us through what you tried and what didn't work?
Thanks for this suggestion! Could you please provide links to the comments that you found on the web so that we can take a look at them?
We do support multipart/form-data in ASP.NET Web API. The support is somewhat different than the MVC support because ASP.NET Web API uses formatters to handle the request body instead of model binding. This means you get the form data as a single object instead of potentially multiple parameters. The benefit of this approach is that you get a convenient formatting abstraction for dealing with multiple formats (XML, JSON, OData, etc). The downside is that the programming model is not as nice for dealing with form data.
You can override how ASP.NET Web API does parameter binding to get the MVC behavior. Ex see http://blogs.msdn.com/b/jmstall/archive/2012/04/18/mvc-style-parameter-binding-for-webapi.aspx. The extension is already available in WebApiContrib. We are considering adding it to the core runtime. If this is what you want, then could you please add a specific suggestion for this feature so that it can be voted on?
As for JSONP, it's not supported by MVC today, although you can implement support for it. The same is true for ASP.NET Web API and there is a JSONP implementation available in WebApiContrib. we are definitely looking at adding cross domain support to ASP.NET Web API including JSONP and CORS. Vote for this UserVoice item if this is what you want: https://aspnet.uservoice.com/forums/147201-asp-net-web-api/suggestions/2632112-out-of-the-box-jsonp-formatter.
Could you please provide an example of model binder arguments that you would like to rename or exclude?
Looking at your blog post I believe you highlight four issues:
1. Why do you need to specify a route name to generate a link when the MVC UrlHelper.Action(…) method don’t require you to specify one?
- Looks like the behavior of MVC is to iterate over the routes and pick the first one that happens to work. Is this the desired behavior?
2. Cannot foreach loop over HttpRouteCollection
3. No way to get the name of a route from the route or the route collection
- This is really an issue with ASP.NET Routing, although it is aggravated by Web API requiring the route name to generate links.
4. Creating a Web API UrlHelper should only require the request, not the controller context
- Fixed! You can create a UrlHelper with just the request.
We don't currently plan on providing support out of the box for the Allow header or OPTIONS requests, but it should be possible to enable this yourself in a cross cutting way using action filters. We are certainly interested in hearing though if the community thinks this needs to be in the box.