Casey Charlton - Insane World

Hang the code, and hang the rules. They're more like guidelines anyway

Where Did filterContext.ActionMethod Go?

Awww cmon Microsoft, play nice with us. I want to do something that should be pretty simple, I just need to know what action is being wrapped by my custom filter in ASP.NET MVC

After a surreal amount of Googling I finally found a blog post that showed where this little bit of information hides, in filterContext.ActionMethod. But I could have sworn I went over that 100x with Intellisense and never saw anything like that. Oh yes, indeed I did, Preview 5 removed this convenient method.

So after a bit of swearing, and a small (140 chars or less) rant on Twitter ... Sidar came up with the answer buried in the ASP.NET forums.

So what is the new location ... would you believe it is now an entry in the dictionary in RouteData??? No, nor would I have believed it. What kind of crazy world is this, when a strongly typed method is replaced by a magic string key to the RouteData dictionary :S

So for now, this fixes it, but I hope MS can make this all nice and strongly typed again, it is a fairly minor thing, but I like my Intellisense, and I hate magic strings:

public override void OnActionExecuting(
                 ActionExecutingContext filterContext)
{
   var methodName = (string)filterContext.RouteData.Values["action"];

p.s. Hmmm this Twitter thing may be the future ...

Published Sep 30 2008, 05:57 PM by Casey Charlton

Filed under: Rants, Sample Code, ASP.NET MVC

Comments

Steve said:

I wondered as well.

Thanks

# September 30, 2008 10:44 PM

Eilon Lipton said:

Hi Casey,

One of the reasons it was removed is that we were making our APIs sufficiently extensible for other controller implementations, such as those used by dynamic languages, for example IronPython. In dynamic languages there is no MethodInfo at all, so we can't give you anything. However, we're thinking of adding back some functionality such as providing the list of attributes on the method.

One thing that's important for us to understand is exactly why you need that data. If what you want is the action name as seen in the URL then it's entirely correct to dig into the RouteData. That's all we would do for you anyway if you wanted just the action name, so we felt there was little value there.

Keep in mind that in Preview 5 and forward the action name doesn't necessarily have anything to do with the name of the method being executed for the action. The two naming concepts are unrelated, so we don't want to mislead people by providing an action name - it wouldn't be clear which name it refers to.

Thanks,

Eilon

# September 30, 2008 11:48 PM

Casey Charlton said:

Eilon,

Thanks very much for that explanation. I appreciate where you are coming from, and also appreciate that the action name should be recovered from the RouteData ... I think my frustration is that more and more magic strings are appearing over our ASP.NET MVC application, and while I fully accept there is almost no chance that this value will change, it is still left open to a lot of guesswork as to what it is in the first place - hence why I posted this to save other people the same frustration ... but this post will soon disappear into the depths of time, and the next generation of MVC developers will have to discover this one all over again.

There is a strongly typed method for ActionParameters on the filterContext, I guess all I am asking is that all other relevant "metadata" be exposed in a similar way, so that the dependency upon the magic string is in the MVC framework, rather than in our codebase.

In this case, the purpose of this attribute/ActionFilter is a templating engine - by adding an attribute of "Templated" the attribute goes off to the relevant template defintions, sets up metadata like Title and Meta tags, loads up all "static" html content from the database, and populates ViewData with it appropriately. Without the method name (or action name specifically) we would not know which template definition to be loading, or which navigation menu options to set.

With this we now have a method that looks like:

[Templated]

public ActionResult Index()

{

return View((string)ViewData["TemplateViewName"]);

}

If we could also eliminate the call into ViewData at the end, that would alsobe cool - have yet to investigate how to write this into the Result as part of the attribute ....

# October 1, 2008 2:52 AM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?