I would tend to think { |controller, block| block.call } would more
clear, especially to people new to the framework and ruby itself.
On 7/5/06, Martin Emde <[EMAIL PROTECTED]> wrote:
Great. Good to see people agree with the idea.
I still think there's a lot of improvement to be made in the filter code so
I will continue making this patch.
I also wanted to see what people's preference was for yielding the action
from a filter. The problem with yield is that yield from a block passed to
meantime_filter (or whatever you want to call it) will call the block passed
to the surrounding method at the time the Proc is created. This means the
filter has to use block.call when it's passed as a Proc, but can call yield
when it's done as a method or an object responding to filter. It would be
nice to eliminate this inconsitency.
An alternate option to yield would be
controller.filter_chain.next
to call the next filter/action.
Yield may make more sense in some cases, but when you're forced to do a proc
like { |controller, block| block.call } sometimes and def
filter(controller); yield; end; other times it may cause confusion.
What seems less confusing to you guys?
-Martin
On 7/2/06, Ezra Zygmuntowicz <[EMAIL PROTECTED] > wrote:
>
>
> Martin-
>
>
> Take a look at this plugin that just came out. I think it does what you
are looking for as far as wrapping actions and yielding to them. Even allows
for a chain of such filters.
>
>
> http://roman2k.free.fr/rails/meantime_filter/0.1.0/rdoc/
>
>
>
> -Ezra
>
>
>
>
> On Jul 2, 2006, at 4:27 PM, Martin Emde wrote:
>
> Well, if you use the new around filter that I'm proposing you won't have a
"before action" and "after action" you'll just have one method that yields
the perform_action for the controller. This way it's unavoidable (without an
exception being raised) for the code not to be run.
>
> For example you would make a filter that acts like a current "around"
filter. (I would call it a "before and after" filter)
>
> def filter(controller)
> if stuff_that_would_normally_be_a_before_action(args)
> yield # runs the action (or the following filter)
> stuff_that_would_normally_be_an_after_action
> else
> # cleanup if before_action stuff failed
> end
> end
>
> This way when the action returns, it should run. If this is not the case,
please let me know a test case I could use to make sure this will work in
the new system.
>
> -Martin
>
>
> On 7/2/06, Julian 'Julik' Tarkhanov < [EMAIL PROTECTED]> wrote:
> >
> > On 2-jul-2006, at 22:49, Andrew Kaspick wrote:
> >
> > > I've definitely had a need for more improved around and after filters.
> > > If an action is cached, any after or around filters will not execute
> > > as processing is basically halted after the cached page is served.
> >
> > The problem here is that there is no assurance that an after-filter
> > will run. That way scoping sometimes propagates
> > through all requests via the class variables. Basically it seems that
> > it would be a nice idea to have around filters which are wrapped
> > in begin/ensure so that the around filter is always fired for both
> > before and after.
> >
> > I looked at how AP handles that and it might be somewhat cumbersome
> > to implement.
> > --
> > Julian 'Julik' Tarkhanov
> > please send all personal mail to
> > me at julik.nl
> >
> >
> > _______________________________________________
> > Rails-core mailing list
> > Rails-core@lists.rubyonrails.org
> >
http://lists.rubyonrails.org/mailman/listinfo/rails-core
> >
>
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
>
>
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
