--- !ruby/object:RI::ClassDescription 
attributes: []

class_methods: []

comment: 
- !ruby/struct:SM::Flow::P 
  body: Filters enable controllers to run shared pre- and post-processing code for its actions. These filters can be used to do authentication, caching, or auditing before the intended action is performed. Or to do localization or output compression after the action has been performed. Filters have access to the request, response, and all the instance variables set by other filters in the chain or by the action (in the case of after filters).
- !ruby/struct:SM::Flow::H 
  level: 2
  text: Filter inheritance
- !ruby/struct:SM::Flow::P 
  body: "Controller inheritance hierarchies share filters downwards, but subclasses can also add or skip filters without affecting the superclass. For example:"
- !ruby/struct:SM::Flow::VERB 
  body: "  class BankController &lt; ActionController::Base\n    before_filter :audit\n\n    private\n      def audit\n        # record the action and parameters in an audit log\n      end\n  end\n\n  class VaultController &lt; BankController\n    before_filter :verify_credentials\n\n    private\n      def verify_credentials\n        # make sure the user is allowed into the vault\n      end\n  end\n"
- !ruby/struct:SM::Flow::P 
  body: Now any actions performed on the BankController will have the audit method called before. On the VaultController, first the audit method is called, then the verify_credentials method. If the audit method renders or redirects, then verify_credentials and the intended action are never called.
- !ruby/struct:SM::Flow::H 
  level: 2
  text: Filter types
- !ruby/struct:SM::Flow::P 
  body: "A filter can take one of three forms: method reference (symbol), external class, or inline method (proc). The first is the most common and works by referencing a protected or private method somewhere in the inheritance hierarchy of the controller by use of a symbol. In the bank example above, both BankController and VaultController use this form."
- !ruby/struct:SM::Flow::P 
  body: "Using an external class makes for more easily reused generic filters, such as output compression. External filter classes are implemented by having a static <tt>filter</tt> method on any class and then passing this class to the filter method. Example:"
- !ruby/struct:SM::Flow::VERB 
  body: "  class OutputCompressionFilter\n    def self.filter(controller)\n      controller.response.body = compress(controller.response.body)\n    end\n  end\n\n  class NewspaperController &lt; ActionController::Base\n    after_filter OutputCompressionFilter\n  end\n"
- !ruby/struct:SM::Flow::P 
  body: The filter method is passed the controller instance and is hence granted access to all aspects of the controller and can manipulate them as it sees fit.
- !ruby/struct:SM::Flow::P 
  body: "The inline method (using a proc) can be used to quickly do something small that doesn't require a lot of explanation. Or just as a quick test. It works like this:"
- !ruby/struct:SM::Flow::VERB 
  body: "  class WeblogController &lt; ActionController::Base\n    before_filter { |controller| head(400) if controller.params[&quot;stop_action&quot;] }\n  end\n"
- !ruby/struct:SM::Flow::P 
  body: "As you can see, the block expects to be passed the controller after it has assigned the request to the internal variables. This means that the block has access to both the request and response objects complete with convenience methods for params, session, template, and assigns. Note: The inline method doesn't strictly have to be a block; any object that responds to call and returns 1 or -1 on arity will do (such as a Proc or an Method object)."
- !ruby/struct:SM::Flow::P 
  body: Please note that around_filters function a little differently than the normal before and after filters with regard to filter types. Please see the section dedicated to around_filters below.
- !ruby/struct:SM::Flow::H 
  level: 2
  text: Filter chain ordering
- !ruby/struct:SM::Flow::P 
  body: "Using <tt>before_filter</tt> and <tt>after_filter</tt> appends the specified filters to the existing chain. That's usually just fine, but some times you care more about the order in which the filters are executed. When that's the case, you can use <tt>prepend_before_filter</tt> and <tt>prepend_after_filter</tt>. Filters added by these methods will be put at the beginning of their respective chain and executed before the rest. For example:"
- !ruby/struct:SM::Flow::VERB 
  body: "  class ShoppingController &lt; ActionController::Base\n    before_filter :verify_open_shop\n\n  class CheckoutController &lt; ShoppingController\n    prepend_before_filter :ensure_items_in_cart, :ensure_items_in_stock\n"
- !ruby/struct:SM::Flow::P 
  body: The filter chain for the CheckoutController is now <tt>:ensure_items_in_cart, :ensure_items_in_stock,</tt> <tt>:verify_open_shop</tt>. So if either of the ensure filters renders or redirects, we'll never get around to see if the shop is open or not.
- !ruby/struct:SM::Flow::P 
  body: You may pass multiple filter arguments of each type as well as a filter block. If a block is given, it is treated as the last argument.
- !ruby/struct:SM::Flow::H 
  level: 2
  text: Around filters
- !ruby/struct:SM::Flow::P 
  body: Around filters wrap an action, executing code both before and after. They may be declared as method references, blocks, or objects responding to <tt>filter</tt> or to both <tt>before</tt> and <tt>after</tt>.
- !ruby/struct:SM::Flow::P 
  body: To use a method as an <tt>around_filter</tt>, pass a symbol naming the Ruby method. Yield (or <tt>block.call</tt>) within the method to run the action.
- !ruby/struct:SM::Flow::VERB 
  body: "  around_filter :catch_exceptions\n\n  private\n    def catch_exceptions\n      yield\n    rescue =&gt; exception\n      logger.debug &quot;Caught exception! #{exception}&quot;\n      raise\n    end\n"
- !ruby/struct:SM::Flow::P 
  body: "To use a block as an <tt>around_filter</tt>, pass a block taking as args both the controller and the action block. You can't call yield directly from an <tt>around_filter</tt> block; explicitly call the action block instead:"
- !ruby/struct:SM::Flow::VERB 
  body: "  around_filter do |controller, action|\n    logger.debug &quot;before #{controller.action_name}&quot;\n    action.call\n    logger.debug &quot;after #{controller.action_name}&quot;\n  end\n"
- !ruby/struct:SM::Flow::P 
  body: "To use a filter object with <tt>around_filter</tt>, pass an object responding to <tt>:filter</tt> or both <tt>:before</tt> and <tt>:after</tt>. With a filter method, yield to the block as above:"
- !ruby/struct:SM::Flow::VERB 
  body: "  around_filter BenchmarkingFilter\n\n  class BenchmarkingFilter\n    def self.filter(controller, &amp;block)\n      Benchmark.measure(&amp;block)\n    end\n  end\n"
- !ruby/struct:SM::Flow::P 
  body: "With <tt>before</tt> and <tt>after</tt> methods:"
- !ruby/struct:SM::Flow::VERB 
  body: "  around_filter Authorizer.new\n\n  class Authorizer\n    # This will run before the action. Redirecting aborts the action.\n    def before(controller)\n      unless user.authorized?\n        redirect_to(login_url)\n      end\n    end\n\n    # This will run after the action if and only if before did not render or redirect.\n    def after(controller)\n    end\n  end\n"
- !ruby/struct:SM::Flow::P 
  body: If the filter has <tt>before</tt> and <tt>after</tt> methods, the <tt>before</tt> method will be called before the action. If <tt>before</tt> renders or redirects, the filter chain is halted and <tt>after</tt> will not be run. See Filter Chain Halting below for an example.
- !ruby/struct:SM::Flow::H 
  level: 2
  text: Filter chain skipping
- !ruby/struct:SM::Flow::P 
  body: "Declaring a filter on a base class conveniently applies to its subclasses, but sometimes a subclass should skip some of its superclass' filters:"
- !ruby/struct:SM::Flow::VERB 
  body: "  class ApplicationController &lt; ActionController::Base\n    before_filter :authenticate\n    around_filter :catch_exceptions\n  end\n\n  class WeblogController &lt; ApplicationController\n    # Will run the :authenticate and :catch_exceptions filters.\n  end\n\n  class SignupController &lt; ApplicationController\n    # Skip :authenticate, run :catch_exceptions.\n    skip_before_filter :authenticate\n  end\n\n  class ProjectsController &lt; ApplicationController\n    # Skip :catch_exceptions, run :authenticate.\n    skip_filter :catch_exceptions\n  end\n\n  class ClientsController &lt; ApplicationController\n    # Skip :catch_exceptions and :authenticate unless action is index.\n    skip_filter :catch_exceptions, :authenticate, :except =&gt; :index\n  end\n"
- !ruby/struct:SM::Flow::H 
  level: 2
  text: Filter conditions
- !ruby/struct:SM::Flow::P 
  body: Filters may be limited to specific actions by declaring the actions to include or exclude. Both options accept single actions (<tt>:only =&gt; :index</tt>) or arrays of actions (<tt>:except =&gt; [:foo, :bar]</tt>).
- !ruby/struct:SM::Flow::VERB 
  body: "  class Journal &lt; ActionController::Base\n    # Require authentication for edit and delete.\n    before_filter :authorize, :only =&gt; [:edit, :delete]\n\n    # Passing options to a filter with a block.\n    around_filter(:except =&gt; :index) do |controller, action_block|\n      results = Profiler.run(&amp;action_block)\n      controller.response.sub! &quot;&lt;/body&gt;&quot;, &quot;#{results}&lt;/body&gt;&quot;\n    end\n\n    private\n      def authorize\n        # Redirect to login unless authenticated.\n      end\n  end\n"
- !ruby/struct:SM::Flow::H 
  level: 2
  text: Filter Chain Halting
- !ruby/struct:SM::Flow::P 
  body: <tt>before_filter</tt> and <tt>around_filter</tt> may halt the request before a controller action is run. This is useful, for example, to deny access to unauthenticated users or to redirect from HTTP to HTTPS. Simply call render or redirect. After filters will not be executed if the filter chain is halted.
- !ruby/struct:SM::Flow::P 
  body: Around filters halt the request unless the action block is called. Given these filters
- !ruby/struct:SM::Flow::VERB 
  body: "  after_filter :after\n  around_filter :around\n  before_filter :before\n"
- !ruby/struct:SM::Flow::P 
  body: "The filter chain will look like:"
- !ruby/struct:SM::Flow::VERB 
  body: "  ...\n  .      #   .  #around (code before yield)\n  .  .       #   .  .  #before (actual filter code is run)\n  .  .  .       #   .  .  .  execute controller action\n  .  .  .  /\n  .  .  ...\n  .  .  /\n  .  #around (code after yield)\n  . /\n  #after (actual filter code is run, unless the around filter does not yield)\n"
- !ruby/struct:SM::Flow::P 
  body: If <tt>around</tt> returns before yielding, <tt>after</tt> will still not be run. The <tt>before</tt> filter and controller action will not be run. If <tt>before</tt> renders or redirects, the second half of <tt>around</tt> and will still run but <tt>after</tt> and the action will not. If <tt>around</tt> fails to yield, <tt>after</tt> will not be run.
constants: []

full_name: ActionController::Filters::ClassMethods
includes: []

instance_methods: 
- !ruby/object:RI::MethodSummary 
  name: after_filter
- !ruby/object:RI::MethodSummary 
  name: append_after_filter
- !ruby/object:RI::MethodSummary 
  name: append_around_filter
- !ruby/object:RI::MethodSummary 
  name: append_before_filter
- !ruby/object:RI::MethodSummary 
  name: around_filter
- !ruby/object:RI::MethodSummary 
  name: before_filter
- !ruby/object:RI::MethodSummary 
  name: filter_chain
- !ruby/object:RI::MethodSummary 
  name: prepend_after_filter
- !ruby/object:RI::MethodSummary 
  name: prepend_around_filter
- !ruby/object:RI::MethodSummary 
  name: prepend_before_filter
- !ruby/object:RI::MethodSummary 
  name: skip_after_filter
- !ruby/object:RI::MethodSummary 
  name: skip_before_filter
- !ruby/object:RI::MethodSummary 
  name: skip_filter
name: ClassMethods
superclass: 
