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.-EzraOn 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.
-MartinOn 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 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
