Monorail: Per-Action Filters

[Avish]

Hi. I hope this is the right place for this.

I want to apply a cross-cutting concern selectively to a set of
controller actions. Normally I'd use a filter, but these can only be
applied on the controller level. My questions are:

1. Is there a good reason why filters can't be declared on a per-
action basis (as in other than "nobody implemented it yet")?

2. I could mimic an action-level filter using a controller-level
filter by reading other attributes from the action itself, but the
problem is I can't find the selected action at the time the filter
runs (the ControllerContext gives me the action name, but that could
map to any number of overloads on a SmartDispatcherController). The
filter is run after the specific overload has been selected, so is
there a way to get to it? Anything from MethodInfo to
ActionMetaDescriptor to IExectuableAction would do.

[Mauricio Scheffer]

Take a look at this: http://randomcode.net.nz/2008/03/03/adding-action-filters-to-monorail-controllers/

Not an perfect implementation, but it works very well.

[Ken Egozi]

mrController.MetaDescriptor.Actions[currentActionName]
might be an IList of MethodInfo (when you have action overloads, on a SmartDispatcherController).
In that case, you'd need a way to retrieve the selected MethodInfo. The Action's name alone would not suffice.
Avishay's concern (it's also mine) could be addressed wither by a way of getting hold of the selected MethodInfo (or ActionMetaDescription), or othrwise by adding Action-Level filters to the mix, which IMO is the easier way out, and will be useful on other scenarios also

--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.delver.com
http://www.musicglue.com
http://www.castleproject.org
http://www.gotfriends.co.il

[Avishay Lavie]

Ken nailed the problem precisely: mapping action names to MethodInfos is easy enough until you have to deal with overloads -- specifically, cases where the filter should run on some overloads but not on others.

[Mauricio Scheffer]

Right, now I remember that I had to modify randomcode's implementation
to take that into account, resulting in some *very* hacky code.
For my particular project, just getting the first MethodInfo from the
list was enough, I try to avoid method overloading on the controllers
as much as possible.

On Aug 4, 11:34 am, Avishay Lavie <some.av...@gmail.com> wrote:
> Ken nailed the problem precisely: mapping action names to MethodInfos is
> easy enough until you have to deal with overloads -- specifically, cases
> where the filter should run on some overloads but not on others.
>
>
>
> On Tue, Aug 4, 2009 at 5:28 PM, Ken Egozi <egoz...@gmail.com> wrote:
> > mrController.MetaDescriptor.Actions[currentActionName]
> > might be an IList of MethodInfo (when you have action overloads, on a
> > SmartDispatcherController).
> > In that case, you'd need a way to retrieve the selected MethodInfo. The
> > Action's name alone would not suffice.
> > Avishay's concern (it's also mine) could be addressed wither by a way of
> > getting hold of the selected MethodInfo (or ActionMetaDescription), or
> > othrwise by adding Action-Level filters to the mix, which IMO is the easier
> > way out, and will be useful on other scenarios also
>
> > On Tue, Aug 4, 2009 at 5:22 PM, Mauricio Scheffer <
> > mauricioschef...@gmail.com> wrote:
>
> >> Take a look at this:

> >>http://randomcode.net.nz/2008/03/03/adding-action-filters-to-monorail...

[Alex Henderson]

I've definitely found myself wanting this in the past, so I would also be interested in action-level filters which work when overloading actions.

Also ASP.Net MVC does action level filtering, it would be nice to keep some feature parity there :)