Is it possible in ASP.NET MVC via some extension/override points to allow a "delegate field" to be used as an "action"?
Something like:
using System;
using System.Web.Mvc;
namespace Company.Web.Controllers
{
public class SwitchboardController : BaseController
{
public Func<ActionResult> Index, Admin, Data, Reports;
public SwitchboardController()
{
// Generic views
Index = Admin = Data = Reports =
() => View();
}
}
}
I know I'm a little hell-bent for this one but if this is possible it'd open up many new ways of making actions. You could, for example, have Django-style generic views in MVC with only a single line of code to define the action or have different ways to factor duplicate logic across multiple controllers.
I'm not quiet sure where would be the place to slap this logic into or how much work would be required to alter something so fundamental in the framework.
You will probably have to build your own Controller factory. This class builds controllers, and implements IControllerFactory. You can inherit from DefaultControllerFactory. Override CreateController() to return your own IController.
Register your controller factory in Application_Start() of MvcApplication using this line:
ControllerBuilder.Current.SetControllerFactory(typeof(MyControllerFactory));
In your implementation of IController, override the Execute method. You can use the RequestContext to decide which delegate to invoke. It would probably be easiest to inherit from ControllerBase, and override Execute in there if you don't want to fully implement IController.
The RequestContext passed into Execute carries a RouteData object. This is a dictionary populated by the routing engine that tells you what action should be invoked, and any parameters. You can get the action name like this:
//context is a RequestContext object passed to IController.Execute()
string actionName = requestContext.RouteData.Values["action"];
You could even define your action as a dictionary, and just pull them out once you get the action name.
One last thing, normal action methods return an ActionResult, which the framework uses to decide which view to render. Once you execute your delegates, I think you'll have to set some stuff manually in your special base controller. I'm not exactly sure what to set or how to get your View executed from here without cracking open the MVC source.
Good luck! This looks like an interesting idea.
As you seem to be implementing a BaseController in your code sample, if you override the Execute (from the IController) you'll be able to interpret the request => action however you like.
No, it isn't. The base controller is looking for methods and not for fields to dispatch an action.
EDIT:
Sorry, I was a bit fast and fixed to the standard classes provided.
You can do that but you have to overwrite the Execute Method in your controller or implement and provide your own IActionInvoker to dispatch the action to fields. Look into the post action processing in detail. It explains the dispatching in detail.
Related
I would like to know the differences between a custom action filter and a custom action selector in ASP.NET MVC.
Say we want to restrict who can have access to an action method on a controller based on some rules. I could either create an action filter extending the ActionFilterAttribute class or extending the ActionMethodSelectionAttribute class, so that I could have something like:
[MyRestriction]
public ActionResult AnyAction(){}
Could anyone explain the differences between them so that I can make the right decision?
If you look at the documentation for ActionMethodSelectionAttribute, you will see at the very bottom of the page that there are a number of other classes that derive from this attribute.
These include:
Microsoft.Web.Mvc.AjaxOnlyAttribute
System.Web.Mvc.AcceptVerbsAttribute
System.Web.Mvc.HttpDeleteAttribute
System.Web.Mvc.HttpGetAttribute
System.Web.Mvc.HttpHeadAttribute
System.Web.Mvc.HttpOptionsAttribute
System.Web.Mvc.HttpPatchAttribute
System.Web.Mvc.HttpPostAttribute
System.Web.Mvc.HttpPutAttribute
System.Web.Mvc.NonActionAttribute
In other words, these are the attributes which control which Action Method is selected during routing when there are several different choices to choose from (ie there are 2 different Index methods, one decorated with [HttpGet] and one with [HttpPost]).
ActionFilterAttribute, on the other hand, is called only when an action is actually executing.
Think about it this way, The selection can run even if the action doesn't execute, the ActionFilter only runs if it does. The selection filter is only used to determine whether the action is a match condition, the action filter is used to do some action before, after, etc.. the action or response is executed.
I am new to MVC. I was going through the asp.net site and found this link where it stated that public methods (actions) cannot be overloaded in controller classes. However in the site it stated that it can be only be possible if i use [AcceptVerbs(HttpVerbs.Post)] with one function.
Can you please explain how does AcceptVerbs helps in overloading the function.What it actually does behind the scene?
And in one of my sample application i am able to overload the function by using [HttpPost] in one function.What else can be used for overloading?
Basically the rule is that you can handle this when it is responding to different types of requests, so Post/Get/Delete. (Any of the items in the HttpVerbs enumeration)
It is due to the way that it does resolution of the method to call in the controller, and specifying the method allows it to handle resolution.
In ASP.NET MVC, incoming request url should match action of controller. In MVC request processing pipeline, first the controller action is selected, and then the parameters for it are inspected and populated. Imagine what happened if controller had two methods with same name but different signature (overloaded).The c# compiler does not complain, as it understands the code, because it can distinguish between methods based on its parameter signature. But ASP.NET MVC request matching mechanism, as mentioned above, cannot - it first does search for action and only after action is selected, it takes look at its parameters. Because of this, "Public actions in controllers cannot be overloaded" - if there're no difference between methods(actions) other than parameters, action selection in MVC will fail to unambiguously select one. This's where ActionMethodSelectorAttribute comes into play. This is the base mechanism for developers to affect the way MVC searches for valid action in specified controller. It has the method IsValidForRequest() that tells MVC wether action can be selected for usage or not. All of [AcceptVerbs], [HttpGet], [HttpPost], [HttpPut], [HttpDelete] and [HttpNonAction] derive from this attribute. And bingo - now the method overloading is possible - although actions have got the same name, one of the attributes above (or your custom attribute derived from ActionMethodSelectorAttribute) can tell MVC wchich action to select and which one to not. And MVC now unambigously knows wchich action is valid for request. Consider example
[HttpGet]
public ActionResult Index()
{
// The above HttpGet.IsValidForRequest() called internally
by mvc will return true only if request is made via HTTP GET
}
[HttpPost]
public ActionResult Index(MyModel model)
{
// The above HttpPost.IsValidForRequest() called internally
by mvc will return true only if request is made via HTTP POST
}
// And so forth with other ActionMethodSelectorAttibute s. As you see, only one action from same named ones is valid for single request when decorated with any of builtin ActionMethodSelectorAttibute
We have a series of ASP.NET MVC controllers that all inherit from a single base controller (that inherits from the Controller class). We are now looking at creating some asynchronous actions, and was wondering if we'd run into any trouble if we just changed the base controller to inherit from AsyncController instead of Controller (meaning all of our controllers would inherit from AsyncController).
Jess,
In my opinion, you'll do no harm as the asynch functionality is only called into play when you follow the conventions of:
public class PortalController : AsyncController
{
public void NewsAsync(string city)
{
AsyncManager.OutstandingOperations.Increment();
NewsService newsService = new NewsService();
newsService.GetHeadlinesCompleted += (sender, e) =>
{
AsyncManager.Parameters["headlines"] = e.Value;
AsyncManager.OutstandingOperations.Decrement();
};
newsService.GetHeadlinesAsync(city);
}
public ActionResult NewsCompleted(string[] headlines)
{
return View("News", new ViewStringModel
{
NewsHeadlines = headlines
});
}
}
the convention being the addition of the News*Async* and the News*Completed* portions in the naming.
see:
async controllers in asp.net mvc 2
Observe that the controller class now derives from AsyncController rather than Controller. In addition, the News action method has been split into methods named NewsAsync and NewsCompleted, which are analagous to the Begin and End methods in asynchronous pages. Logically, the controller still exposes a single action method named News. But physically, the method implementation has been broken up using a variation on the async pattern used throughout the .NET framework.
If you don't change anything in your inherited controller code, then no async activty will be initiated. However, as stated by Robert above (or below maybe :-)), you could decorate the actions on a needs must basis to keep the intention clear, tho', i personally think the convention should show that up clearly.
certainly worthy of debate.
MVC 4 doesn't have an asynch controller - see the source:
namespace System.Web.Mvc
{
// Controller now supports asynchronous operations.
// This class only exists
// a) for backwards compat for callers that derive from it,
// b) ActionMethodSelector can detect it to bind to ActionAsync/ActionCompleted patterns.
public abstract class AsyncController : Controller
{
}
}
See my tutorial Using Asynchronous Methods in ASP.NET MVC 4
If you set a breakpoint in your Action method and observe the callstack (with Show External code enabled), you will see that there are several additional steps required to invoke a synchronous action residing in an AsyncController vs. in a standard Controller. Namely the AsyncControllerActionInvoker invokes Begin/End style methods ending with BeginInvokeSynchronousActionMethod. I don't know how much overhead these extra calls contribute, but it is something to be aware of before you blindly extend all your controllers from AsyncController even where no Async actions exist.
You should be fine doing that since AsyncController already inherits from Controller.
See here for more information
The remarks on that page are quite useful for determining whether you're doing the right thing by inheriting from AsyncController and offers a nice guide to keep you on track.
The use of an Async Controller depends on whether you want to wait for any particular task or step to complete before going on to the next task. The problem is akin to buying something from Amazon before the money from your paycheck hits your checking account.
For typical web applications, I would say this is not advisable. The web server is already very parallel, so the only advantage would be speeding up responsiveness to the user. For many operations this benefit would be negligible.
I would reserve the Async Controllers for long-running processes in the background, where it is impractical to wait for the task to complete before returning the web page back to the user's control.
NOTE: If you have a copy of a .NET disassembler (or the ASP.NET MVC source), you can open up the AsyncController class and have a look at the code. That should give you a pretty good idea whether or not you can use the AsyncController as an ordinary Controller.
The article I linked to below says this: "Controllers that derive from AsyncController enable ASP.NET to process asynchronous requests, and they can still service synchronous action methods."
http://msdn.microsoft.com/en-us/library/ee728598.aspx
I'd like to get access to the current executing Controller so I can offload the return of the appropriate ActionResult onto a helper method. To this end, I'm looking for the equivalent of what I would have thought would be ControllerContext.Current but isn't. Thanks!
Edit for clarification: I've got a generic form control which is JavaScript-based but I'd like to add an option so that it works with noscript. At the moment my Controller sets the ViewData.Model to a JSON-ified Models.FormResponse<T>.
This FormReponse is set up with the status of the post and any error messages that were generated, so I'd like a GetActionResult() method which does the script/noscript check (a hidden form input) and either:
Sets the Model to the JSONed FormResponse and returns a View(), or
Serializes the FormResponse to the Session and returns a Redirect().
As this obviously changes the return value and I don't want to do the check myself every time, I need to call View or Redirect from the FormResponse's GetActionResult method in order to call this as:
return formResponse.GetActionResult();
I know with a more astronautical design this could be made even more robust but as the noscript option is not a major feature at the moment, I just need to get a quick solution working that doesn't break other things.
Update #2
The following, implemented in an ActionResult class, does the job for me. Thanks CVertex!
public override void ExecuteResult(ControllerContext context)
{
if (CMSEnvironment.NoScript)
{
Oracle.Response.Redirect(Oracle.Request.UrlReferrer.ToString(), true);
}
context.Controller.ViewData.Model = _model.ToJSON();
new ViewResult()
{
ViewName = Areas.Site.Helpers.SharedView.Service,
ViewData = context.Controller.ViewData
}.ExecuteResult(context);
}
Statics are bad for testability, and very much discouraged in MVC.
Why do you want to access the current controller and action method?
The best way to do this is to implement your own ActionFilter.
This gives you a means of intercepting requests before or after actions methods execute.
EDIT:
By intercepting the result inside OnActionExecuted of a filter, you can do your noscript/script checks and modify your ViewData accordingly for consumption by the View.
Inside OnActionExecuted, you can also do the noscript check and have complete control over the final ActionResult or the ViewData, as you please.
Or, you can write your own ActionResult that makes all these decisions.
So, your controller action ultimately does
return new MyActionResult(format_and_view_agnostic_model_object);
There doesn't appear to be a way to navigate to the current Controller from a thread. That is you could get the ControllerBuilder and you can get the MvcHttpHandler but neither then lets you access the controller instance that the handler is using.
I'm trying to pass ViewData to my asp.net mvc masterpage for an mvc usercontrol that I keep on a masterpage. For example, I created a dropdownlist of names as an mvc usercontrol and I put that in my masterpage.
The problem I am running into is passing the ViewData to the masterpage. I found this article from Microsoft which has a decent solution but I was wondering if there are other "better" solutions out there. The thing I don't like about the solution in the link is that I have to change every controller to inherit from a new controller class.
http://www.asp.net/learn/MVC/tutorial-13-cs.aspx
Edit: The problem I am looking at is the fact that if I place a user control in my masterpage that relies on ViewData, I have to REPEATEDLY include that ViewData for every single page that uses said masterpage. It's possible the solution in the link above is the best solution but I was hoping there were other alternatives.
The master page already has access to the ViewData. If you want strongly typed access to it, you need to do two things:
Put the master page stuff in a base class (e.g. CommonViewData)
Have you master page inherit from the generic ViewMasterPage<> class:
" %>
Could you possibly use the OnActionExecuting method on a base controller class and populate the view data there?
Something like:
protected override void OnActionExecuting(ActionExecutingContext context)
{
context.Controller.ViewData.Model = GetDataForControl();
}
I haven't tried it so it's just a thought...
For what it's worth, I am using the method from that tutorial in a current project and it works very well.
What you can also do, if it is data that is somewhat static (like a menu that doesn't change much), is to put the object on the cache so your database isn't called for every controller initialisation.
I usually use an abstract controller class for my MasterPage, it is the best solution, because the MasterPage is like an "abstract view". But I override the MasgerPageController View() method to include the viewdata.
protected override ViewResult View(string viewName, string masterName, object model)
{
this.ViewData["menu"] = this.PagesRepository.GetPublishPages();
return base.View(viewName, masterName, model);
}
I don't quite get your problem...
The problem I am looking at is the fact that if I place a user control in my masterpage that relies on ViewData, I have to REPEATEDLY include that ViewData for every single page that uses said masterpage.
Well yeah... of course you do. If you have a usercontrol in your master page then of course you're going to have to pass the required data for that usercontrol for every action & view that uses that masterpage.
It's not like you have to repeat yourself if you are just inheriting from a base controller.
Is your issue the fact that some controllers have actions that both do and don't call views that derive from that particular masterpage? So therefore if you are implementing a base controller, the actions that don't use that particular masterpage will still have the viewdata for it...? (If all that makes sense ;-)
I think the solution suggested does work but not the ideal solution. If we put the code in the BaseController constructor it is going to be called even for Action methods which does not have a MasterPages (e.g Post methods and Ajax methods).
I think a better solution(not ideal) is to call Html.Action method in the Master page.