diff options
| author | Zachary Scott <e@zzak.io> | 2015-04-09 23:28:02 -0700 |
|---|---|---|
| committer | Zachary Scott <e@zzak.io> | 2015-04-09 23:28:02 -0700 |
| commit | f0d3c920a5aeb3babc35500e13288e148238b65e (patch) | |
| tree | 384686a1ebbf7af2d04ebc177793db252faafefb /guides | |
| parent | bfe6507f59426153c1991bf9de740c0393d08873 (diff) | |
| parent | e9df18436b1848dba3dc259fb0c3d308a463e065 (diff) | |
| download | rails-f0d3c920a5aeb3babc35500e13288e148238b65e.tar.gz rails-f0d3c920a5aeb3babc35500e13288e148238b65e.tar.bz2 rails-f0d3c920a5aeb3babc35500e13288e148238b65e.zip | |
Merge pull request #19716 from yui-knk/fix/filter_name
[ci skip] Downcases filter names
Diffstat (limited to 'guides')
| -rw-r--r-- | guides/source/action_controller_overview.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/guides/source/action_controller_overview.md b/guides/source/action_controller_overview.md index 8c1551f4a1..a9725964a2 100644 --- a/guides/source/action_controller_overview.md +++ b/guides/source/action_controller_overview.md @@ -671,7 +671,7 @@ Filters are methods that are run before, after or "around" a controller action. Filters are inherited, so if you set a filter on `ApplicationController`, it will be run on every controller in your application. -"Before" filters may halt the request cycle. A common "before" filter is one which requires that a user is logged in for an action to be run. You can define the filter method this way: +"before" filters may halt the request cycle. A common "before" filter is one which requires that a user is logged in for an action to be run. You can define the filter method this way: ```ruby class ApplicationController < ActionController::Base @@ -704,9 +704,9 @@ Now, the `LoginsController`'s `new` and `create` actions will work as before wit In addition to "before" filters, you can also run filters after an action has been executed, or both before and after. -"After" filters are similar to "before" filters, but because the action has already been run they have access to the response data that's about to be sent to the client. Obviously, "after" filters cannot stop the action from running. +"after" filters are similar to "before" filters, but because the action has already been run they have access to the response data that's about to be sent to the client. Obviously, "after" filters cannot stop the action from running. -"Around" filters are responsible for running their associated actions by yielding, similar to how Rack middlewares work. +"around" filters are responsible for running their associated actions by yielding, similar to how Rack middlewares work. For example, in a website where changes have an approval workflow an administrator could be able to preview them easily, just apply them within a transaction: |