Thanks for feedback John, I think I'll start the branch from scratch another time (making sure my line ending is ok) to bring only things that are necessary (FilterProcessor to move logic out from Controller and such things) in steps that I know could be merged even before action level filters are completed.
I think I've been a bit off track with changes that are necessary for action filters just by the fact that the code is bit more spreaded that I would think (mainly in Controller), I've to get into it another time. Do you think that action filter execution should be the responsibility of the action executor or is it prefered to keep it at the controller level (would be required for after rendering) I'm not sure if we should ditch the after rendering for action level filters, it would feel inconsistent, and lead to runtime error (we should throw if such thing happen), sure it's not easy to get it correctly but should it be dropped? On Jun 27, 5:21 am, John Simons <[email protected]> wrote: > 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-... > > 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 > athttp://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.
