mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
update guides to use _action callbacks [ci skip]
This commit is contained in:
parent
69163ccae6
commit
f19e41fb16
6 changed files with 21 additions and 21 deletions
|
@ -434,7 +434,7 @@ Filters are inherited, so if you set a filter on `ApplicationController`, it wil
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
class ApplicationController < ActionController::Base
|
class ApplicationController < ActionController::Base
|
||||||
before_filter :require_login
|
before_action :require_login
|
||||||
|
|
||||||
private
|
private
|
||||||
|
|
||||||
|
@ -458,11 +458,11 @@ end
|
||||||
|
|
||||||
The method simply stores an error message in the flash and redirects to the login form if the user is not logged in. If a "before" filter renders or redirects, the action will not run. If there are additional filters scheduled to run after that filter, they are also cancelled.
|
The method simply stores an error message in the flash and redirects to the login form if the user is not logged in. If a "before" filter renders or redirects, the action will not run. If there are additional filters scheduled to run after that filter, they are also cancelled.
|
||||||
|
|
||||||
In this example the filter is added to `ApplicationController` and thus all controllers in the application inherit it. This will make everything in the application require the user to be logged in in order to use it. For obvious reasons (the user wouldn't be able to log in in the first place!), not all controllers or actions should require this. You can prevent this filter from running before particular actions with `skip_before_filter`:
|
In this example the filter is added to `ApplicationController` and thus all controllers in the application inherit it. This will make everything in the application require the user to be logged in in order to use it. For obvious reasons (the user wouldn't be able to log in in the first place!), not all controllers or actions should require this. You can prevent this filter from running before particular actions with `skip_before_action`:
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
class LoginsController < ApplicationController
|
class LoginsController < ApplicationController
|
||||||
skip_before_filter :require_login, only: [:new, :create]
|
skip_before_action :require_login, only: [:new, :create]
|
||||||
end
|
end
|
||||||
```
|
```
|
||||||
|
|
||||||
|
@ -480,7 +480,7 @@ For example, in a website where changes have an approval workflow an administrat
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
class ChangesController < ActionController::Base
|
class ChangesController < ActionController::Base
|
||||||
around_filter :wrap_in_transaction, only: :show
|
around_action :wrap_in_transaction, only: :show
|
||||||
|
|
||||||
private
|
private
|
||||||
|
|
||||||
|
@ -502,13 +502,13 @@ You can choose not to yield and build the response yourself, in which case the a
|
||||||
|
|
||||||
### Other Ways to Use Filters
|
### Other Ways to Use Filters
|
||||||
|
|
||||||
While the most common way to use filters is by creating private methods and using *_filter to add them, there are two other ways to do the same thing.
|
While the most common way to use filters is by creating private methods and using *_action to add them, there are two other ways to do the same thing.
|
||||||
|
|
||||||
The first is to use a block directly with the *_filter methods. The block receives the controller as an argument, and the `require_login` filter from above could be rewritten to use a block:
|
The first is to use a block directly with the *_action methods. The block receives the controller as an argument, and the `require_login` filter from above could be rewritten to use a block:
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
class ApplicationController < ActionController::Base
|
class ApplicationController < ActionController::Base
|
||||||
before_filter do |controller|
|
before_action do |controller|
|
||||||
redirect_to new_login_url unless controller.send(:logged_in?)
|
redirect_to new_login_url unless controller.send(:logged_in?)
|
||||||
end
|
end
|
||||||
end
|
end
|
||||||
|
@ -520,7 +520,7 @@ The second way is to use a class (actually, any object that responds to the righ
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
class ApplicationController < ActionController::Base
|
class ApplicationController < ActionController::Base
|
||||||
before_filter LoginFilter
|
before_action LoginFilter
|
||||||
end
|
end
|
||||||
|
|
||||||
class LoginFilter
|
class LoginFilter
|
||||||
|
@ -648,7 +648,7 @@ HTTP digest authentication is superior to the basic authentication as it does no
|
||||||
class AdminController < ApplicationController
|
class AdminController < ApplicationController
|
||||||
USERS = { "lifo" => "world" }
|
USERS = { "lifo" => "world" }
|
||||||
|
|
||||||
before_filter :authenticate
|
before_action :authenticate
|
||||||
|
|
||||||
private
|
private
|
||||||
|
|
||||||
|
@ -828,7 +828,7 @@ end
|
||||||
|
|
||||||
class ClientsController < ApplicationController
|
class ClientsController < ApplicationController
|
||||||
# Check that the user has the right authorization to access clients.
|
# Check that the user has the right authorization to access clients.
|
||||||
before_filter :check_authorization
|
before_action :check_authorization
|
||||||
|
|
||||||
# Note how the actions don't have to worry about all the auth stuff.
|
# Note how the actions don't have to worry about all the auth stuff.
|
||||||
def edit
|
def edit
|
||||||
|
|
|
@ -447,17 +447,17 @@ end
|
||||||
Action Mailer Callbacks
|
Action Mailer Callbacks
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
Action Mailer allows for you to specify a `before_filter`, `after_filter` and 'around_filter'.
|
Action Mailer allows for you to specify a `before_action`, `after_action` and 'around_action'.
|
||||||
|
|
||||||
* Filters can be specified with a block or a symbol to a method in the mailer class similar to controllers.
|
* Filters can be specified with a block or a symbol to a method in the mailer class similar to controllers.
|
||||||
|
|
||||||
* You could use a `before_filter` to prepopulate the mail object with defaults, delivery_method_options or insert default headers and attachments.
|
* You could use a `before_action` to prepopulate the mail object with defaults, delivery_method_options or insert default headers and attachments.
|
||||||
|
|
||||||
* You could use an `after_filter` to do similar setup as a `before_filter` but using instance variables set in your mailer action.
|
* You could use an `after_action` to do similar setup as a `before_action` but using instance variables set in your mailer action.
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
class UserMailer < ActionMailer::Base
|
class UserMailer < ActionMailer::Base
|
||||||
after_filter :set_delivery_options, :prevent_delivery_to_guests, :set_business_headers
|
after_action :set_delivery_options, :prevent_delivery_to_guests, :set_business_headers
|
||||||
|
|
||||||
def feedback_message(business, user)
|
def feedback_message(business, user)
|
||||||
@business = business
|
@business = business
|
||||||
|
|
|
@ -1486,7 +1486,7 @@ You can use the same technique to localize the rescue files in your public direc
|
||||||
Since Rails doesn't restrict the symbols that you use to set I18n.locale, you can leverage this system to display different content depending on anything you like. For example, suppose you have some "expert" users that should see different pages from "normal" users. You could add the following to `app/controllers/application.rb`:
|
Since Rails doesn't restrict the symbols that you use to set I18n.locale, you can leverage this system to display different content depending on anything you like. For example, suppose you have some "expert" users that should see different pages from "normal" users. You could add the following to `app/controllers/application.rb`:
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
before_filter :set_expert_locale
|
before_action :set_expert_locale
|
||||||
|
|
||||||
def set_expert_locale
|
def set_expert_locale
|
||||||
I18n.locale = :expert if current_user.expert?
|
I18n.locale = :expert if current_user.expert?
|
||||||
|
|
|
@ -104,7 +104,7 @@ Let's say you only wanted authenticated users to call actions on `ProductsContro
|
||||||
```ruby
|
```ruby
|
||||||
class ProductsController < ActionController
|
class ProductsController < ActionController
|
||||||
|
|
||||||
before_filter :authenticate
|
before_action :authenticate
|
||||||
caches_action :index
|
caches_action :index
|
||||||
|
|
||||||
def index
|
def index
|
||||||
|
|
|
@ -134,10 +134,10 @@ However, you would probably like to **provide support for more locales** in your
|
||||||
|
|
||||||
WARNING: You may be tempted to store the chosen locale in a _session_ or a <em>cookie</em>, however **do not do this**. The locale should be transparent and a part of the URL. This way you won't break people's basic assumptions about the web itself: if you send a URL to a friend, they should see the same page and content as you. A fancy word for this would be that you're being [<em>RESTful</em>](http://en.wikipedia.org/wiki/Representational_State_Transfer. Read more about the RESTful approach in [Stefan Tilkov's articles](http://www.infoq.com/articles/rest-introduction). Sometimes there are exceptions to this rule and those are discussed below.
|
WARNING: You may be tempted to store the chosen locale in a _session_ or a <em>cookie</em>, however **do not do this**. The locale should be transparent and a part of the URL. This way you won't break people's basic assumptions about the web itself: if you send a URL to a friend, they should see the same page and content as you. A fancy word for this would be that you're being [<em>RESTful</em>](http://en.wikipedia.org/wiki/Representational_State_Transfer. Read more about the RESTful approach in [Stefan Tilkov's articles](http://www.infoq.com/articles/rest-introduction). Sometimes there are exceptions to this rule and those are discussed below.
|
||||||
|
|
||||||
The _setting part_ is easy. You can set the locale in a `before_filter` in the `ApplicationController` like this:
|
The _setting part_ is easy. You can set the locale in a `before_action` in the `ApplicationController` like this:
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
before_filter :set_locale
|
before_action :set_locale
|
||||||
|
|
||||||
def set_locale
|
def set_locale
|
||||||
I18n.locale = params[:locale] || I18n.default_locale
|
I18n.locale = params[:locale] || I18n.default_locale
|
||||||
|
@ -160,7 +160,7 @@ One option you have is to set the locale from the domain name where your applica
|
||||||
You can implement it like this in your `ApplicationController`:
|
You can implement it like this in your `ApplicationController`:
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
before_filter :set_locale
|
before_action :set_locale
|
||||||
|
|
||||||
def set_locale
|
def set_locale
|
||||||
I18n.locale = extract_locale_from_tld || I18n.default_locale
|
I18n.locale = extract_locale_from_tld || I18n.default_locale
|
||||||
|
@ -203,7 +203,7 @@ This solution has aforementioned advantages, however, you may not be able or may
|
||||||
|
|
||||||
### Setting the Locale from the URL Params
|
### Setting the Locale from the URL Params
|
||||||
|
|
||||||
The most usual way of setting (and passing) the locale would be to include it in URL params, as we did in the `I18n.locale = params[:locale]` _before_filter_ in the first example. We would like to have URLs like `www.example.com/books?locale=ja` or `www.example.com/ja/books` in this case.
|
The most usual way of setting (and passing) the locale would be to include it in URL params, as we did in the `I18n.locale = params[:locale]` _before_action_ in the first example. We would like to have URLs like `www.example.com/books?locale=ja` or `www.example.com/ja/books` in this case.
|
||||||
|
|
||||||
This approach has almost the same set of advantages as setting the locale from the domain name: namely that it's RESTful and in accord with the rest of the World Wide Web. It does require a little bit more work to implement, though.
|
This approach has almost the same set of advantages as setting the locale from the domain name: namely that it's RESTful and in accord with the rest of the World Wide Web. It does require a little bit more work to implement, though.
|
||||||
|
|
||||||
|
|
|
@ -688,7 +688,7 @@ NOTE: _When sanitizing, protecting or verifying something, whitelists over black
|
||||||
|
|
||||||
A blacklist can be a list of bad e-mail addresses, non-public actions or bad HTML tags. This is opposed to a whitelist which lists the good e-mail addresses, public actions, good HTML tags and so on. Although sometimes it is not possible to create a whitelist (in a SPAM filter, for example), _prefer to use whitelist approaches_:
|
A blacklist can be a list of bad e-mail addresses, non-public actions or bad HTML tags. This is opposed to a whitelist which lists the good e-mail addresses, public actions, good HTML tags and so on. Although sometimes it is not possible to create a whitelist (in a SPAM filter, for example), _prefer to use whitelist approaches_:
|
||||||
|
|
||||||
* Use before_filter only: [...] instead of except: [...]. This way you don't forget to turn it off for newly added actions.
|
* Use before_action only: [...] instead of except: [...]. This way you don't forget to turn it off for newly added actions.
|
||||||
* Use attr_accessible instead of attr_protected. See the mass-assignment section for details
|
* Use attr_accessible instead of attr_protected. See the mass-assignment section for details
|
||||||
* Allow <strong> instead of removing <script> against Cross-Site Scripting (XSS). See below for details.
|
* Allow <strong> instead of removing <script> against Cross-Site Scripting (XSS). See below for details.
|
||||||
* Don't try to correct user input by blacklists:
|
* Don't try to correct user input by blacklists:
|
||||||
|
|
Loading…
Reference in a new issue