Hey all, I need to get your feedback on something. We want to remove the ActionMethod property on Action Filter Contexts, but want to get a sense if that would cause problems for anyone. Most of the information you get from the property is available to you
via the RouteValueDictionary. The reason for the proposed change is we might want to change the mechanism from reflection to something else in the future. By having a property of type MethodInfo there now, we bake that signature into the context. We don't
have time to do the full change we'd like now, so it'd be better if we simply removed the property and added it back later with the proper signature. Any strong objections?
Phil Haack (http://haacked.com/)
Senior Program Manager, Microsoft
I think that's a no-brainer. Make the switch. It means decoupling yourself from implementation details (ie: getting action name from reflection) and improving the framework. The change on our end would be pretty small.
Given the route values we could always reflect and get our own MethodInfo if we were totally dependent on it.
I just did a quick search through the mvccontrib code, and the only place I've ever used it is to determine the name of the action being executed, but as you say this can easily be extracted from the routedata instead.
There is the edge case where you're using a custom ControllerActionInvoker to select action methods, and then you couldn't necessarily determine which action method had been selected just by looking at RouteData. Still, I can't imagine a realistic scenario
where this would be an unsolveable problem.
Sounds like a sensible change to me. No objections!
Haacked
Contributor
6901 Points
412 Posts
RFC - Removing ActionMethod property from Action Filter Contexts
Aug 05, 2008 06:40 PM|LINK
Hey all, I need to get your feedback on something. We want to remove the ActionMethod property on Action Filter Contexts, but want to get a sense if that would cause problems for anyone. Most of the information you get from the property is available to you via the RouteValueDictionary. The reason for the proposed change is we might want to change the mechanism from reflection to something else in the future. By having a property of type MethodInfo there now, we bake that signature into the context. We don't have time to do the full change we'd like now, so it'd be better if we simply removed the property and added it back later with the proper signature. Any strong objections?
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?
subdigital
Contributor
2105 Points
445 Posts
ASPInsiders
Re: RFC - Removing ActionMethod property from Action Filter Contexts
Aug 05, 2008 06:46 PM|LINK
I think that's a no-brainer. Make the switch. It means decoupling yourself from implementation details (ie: getting action name from reflection) and improving the framework. The change on our end would be pretty small.
Given the route values we could always reflect and get our own MethodInfo if we were totally dependent on it.
http://www.flux88.com
ASP.NET MVP
Certified ScrumMaster
ASPInsider
MCSD
JeremyS
Member
506 Points
99 Posts
Re: RFC - Removing ActionMethod property from Action Filter Contexts
Aug 05, 2008 06:51 PM|LINK
I just did a quick search through the mvccontrib code, and the only place I've ever used it is to determine the name of the action being executed, but as you say this can easily be extracted from the routedata instead.
derikwhittak...
Member
10 Points
6 Posts
Re: RFC - Removing ActionMethod property from Action Filter Contexts
Aug 05, 2008 06:55 PM|LINK
I see no real need for it. Nuke it.
I am all for breaking changes in future releases if it is for the better.
SteveSanders...
Member
432 Points
119 Posts
Microsoft
Re: RFC - Removing ActionMethod property from Action Filter Contexts
Aug 05, 2008 07:29 PM|LINK
There is the edge case where you're using a custom ControllerActionInvoker to select action methods, and then you couldn't necessarily determine which action method had been selected just by looking at RouteData. Still, I can't imagine a realistic scenario where this would be an unsolveable problem.
Sounds like a sensible change to me. No objections!
http://blog.codeville.net/