Hi Gauthier, Had a look at your fork, and it looks like you having issues dealing with line endings because most of your changes come as the whole file is changed so is really hard to figure out what is new and what is the same. Regarding the code, I'm of the opinion that you should make it very similar to what is already done with Controller filters but drop the AfterRendering (not sure why this setting exists for controller filters anyway?) Currently the ExecutionOrder is used across each ExecuteWhen which is the way I would recommend you to keep it.
Very good idea to refactor out the filter logic from the controller as much as possible. Cheers John ________________________________ From: Gauthier Segay <[email protected]> To: Castle Project Development List <[email protected]> Sent: Sun, 27 June, 2010 12:06:18 PM Subject: Re: MonoRail: action level filters Hello, I'm currently working on a branch here to introduce a barebone action level filter implementation: http://github.com/smoothdeveloper/Castle.MonoRail/tree/actionfilters-frameworkchanges I wanted to ask if there are expected semantic, such as BeforeAction CurrentControllerFilters CurrentActionFilters AfterAction CurrentControllerFilters CurrentActionFilters AfterRendering CurrentControllerFilters CurrentActionFilters or should it happen another way? or should filters be plainly ordered by ExecutionOrder accross the complete context? Also, right now, I'm unsure how to hook AfterRendering action level filters, it will probably need to hook a new event on IController but I'm unsure we want to go this route. On my way, I'm refactoring the filter processing logic out of the Controller implementation, any comment on the branch is welcome. On Jun 20, 11:42 am, Gauthier Segay <[email protected]> wrote: > Coming back on that action level filter discussion I've left here: > > it's not working/existing in the current codebase, currently > FilterAttribute is defined valid only for classes, so you can't > compile a controller having a Filter attribute on it's method > > I've seen this blog post: > > http://randomcode.net.nz/2008/03/03/adding-action-filters-to-monorail... > > and I'm looking to get this feature into the main code base, I have > some design questions about it: > > - wouldn't it be preferable to use the same Filter Attribute rather > than introducing another one as done in the article? > - ActionMetaDescriptor seems to be the right place to have a reference > of action level filters, does it feel right to add an > ActionLevelFilters member here? > - how are dynamic actions expected to deal with filters? should we > take care of applying filters that might declared on dynamic actions? > should we support it at the class or method level? > > another question concerning dynamic actions, I would expect these to > be handled the same way as controller concerning attributes (return > binder, filters, layout overriding, helpers), I think this part is not > clear, would it be helpfull to specify what is ok and at which level > these attributes have to be defined for dynamic actions? > > Thanks for your feedback -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
