mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
Add guide for inline around_action
This commit adds a test to ensure the behavior of inline `around_action` calls, as well as a change to the guides to call out this alternate use of `around_action`. Closes #37616
This commit is contained in:
parent
b674f04756
commit
012b1e3281
2 changed files with 31 additions and 0 deletions
|
@ -546,6 +546,31 @@ class FilterTest < ActionController::TestCase
|
||||||
end
|
end
|
||||||
end
|
end
|
||||||
|
|
||||||
|
def test_around_action_can_use_yield_inline_with_passed_action
|
||||||
|
controller = Class.new(ActionController::Base) do
|
||||||
|
around_action do |c, a|
|
||||||
|
c.values << "before"
|
||||||
|
a.call
|
||||||
|
c.values << "after"
|
||||||
|
end
|
||||||
|
|
||||||
|
def index
|
||||||
|
values << "action"
|
||||||
|
render inline: "index"
|
||||||
|
end
|
||||||
|
|
||||||
|
def values
|
||||||
|
@values ||= []
|
||||||
|
end
|
||||||
|
end.new
|
||||||
|
|
||||||
|
assert_nothing_raised do
|
||||||
|
test_process(controller, "index")
|
||||||
|
end
|
||||||
|
|
||||||
|
assert_equal ["before", "action", "after"], controller.values
|
||||||
|
end
|
||||||
|
|
||||||
def test_after_actions_are_not_run_if_around_action_does_not_yield
|
def test_after_actions_are_not_run_if_around_action_does_not_yield
|
||||||
controller = NonYieldingAroundFilterController.new
|
controller = NonYieldingAroundFilterController.new
|
||||||
test_process(controller, "index")
|
test_process(controller, "index")
|
||||||
|
|
|
@ -753,6 +753,12 @@ end
|
||||||
|
|
||||||
Note that the filter in this case uses `send` because the `logged_in?` method is private and the filter does not run in the scope of the controller. This is not the recommended way to implement this particular filter, but in more simple cases it might be useful.
|
Note that the filter in this case uses `send` because the `logged_in?` method is private and the filter does not run in the scope of the controller. This is not the recommended way to implement this particular filter, but in more simple cases it might be useful.
|
||||||
|
|
||||||
|
Specifically for `around_action`, the block also yields in the `action`:
|
||||||
|
|
||||||
|
```ruby
|
||||||
|
around_action { |_controller, action| time(&action) }
|
||||||
|
```
|
||||||
|
|
||||||
The second way is to use a class (actually, any object that responds to the right methods will do) to handle the filtering. This is useful in cases that are more complex and cannot be implemented in a readable and reusable way using the two other methods. As an example, you could rewrite the login filter again to use a class:
|
The second way is to use a class (actually, any object that responds to the right methods will do) to handle the filtering. This is useful in cases that are more complex and cannot be implemented in a readable and reusable way using the two other methods. As an example, you could rewrite the login filter again to use a class:
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
|
|
Loading…
Reference in a new issue