Do we need Name and DisplayName on ActionDescriptor

[rynowak]

It's not clear what the difference is between these. I think we probably want to remove Name and add ActionName to ControllerActionDescriptor - the more specialized type

[Eilon]

No we don't need both on AD. We should rename Name to ActionName and move it to ControllerActionDescriptor. And DisplayName should stay as-is because it's just for debugging; it has no programmatic usage.

[Eilon]

3-Done? 😄

[javiercn]

Done done

[senritsu]

Now that Name is moved, how would i go about getting the action name inside an IActionFilter? The methods only get a parameter of type ActionExecutingContext. That in turn contains the ActionDescriptor, but no ControllerActionDescriptor. Do i just cast it?

[LandryDubus]

I had the same issue as @senritsu as I am trying to migrate my project to RTM.

Here is what I did:

public void OnActionExecuting(IOLoggingAttribute attribute, ActionExecutingContext context) { var controllerActionDescriptor = context.ActionDescriptor as ControllerActionDescriptor; _logger.LogInformation(string.Format("Enter --> Controller : {0} | Action : {1} | Arguments : ( {2} )", context.RouteData?.Values["controller"], controllerActionDescriptor?.ActionName, string.Join(" , ", context.ActionArguments?.Values))); }

We can cast ActionDescriptor to ControllerActionDescriptor

[rynowak]

You can either use RouteData.Values["action"] which may vary on casing or cast it. Can you clue me in to what this is for?

If this is for logging, the framework already logs enter/exit, what can we fix in the framework to make this meet your needs?

[senritsu]

I think it is used for excluding a few actions from a global action filter. Why it does not use attributes or something to achieve that, i don't know. If casting works that is fine for now. Sooner or later the code will have to be refactored to be not horrible anyways.

[rynowak]

I think it is used for excluding a few actions from a global action filter.

I'd suggest doing something like this to make not horrible as you put it 😆. This is a common pattern that we've used inside the framework, example here

public interface IFooConcernFilter
{
    // Just a marker
}

public class MyGlobalFooConcernFilter : IFooConcernFilter, IActionFilter
{
    public void OnActionExecuting(...)
    {
        if (!IsClosestFooConcernFilter(context)
        {
            return;
        }
    }

    private bool IsClosestFooConcernFilter(FilterContext context)
    {
            // Determine if this instance is the 'effective' foo concern policy.
            for (var i = filters.Count - 1; i >= 0; i--)
            {
                var filter = filters[i];
                if (filter is IFooConcernFilter)
                {
                    return object.ReferenceEquals(this, filter);
                }
            }

            Debug.Fail("The current instance should be in the list of filters.");
            return false;
    }
}

public class IgnoreFooConcernAttribute : Attribute, IFooConcernFilter
{
    // Also just a marker
}

This gives [IgnoreFooConcern] overriding behavior. If you slap that on a controller or action, then the global filter knows to shut itself off.