Path: | lib/merb-core/controller/abstract_controller.rb |
Last Update: | Mon Aug 16 18:50:21 -0600 2010 |
In Merb, views are actually methods on controllers. This provides not-insignificant speed benefits, as well as preventing us from needing to copy over instance variables, which we think is proof that everything belongs in one class to begin with.
Unfortunately, this means that view helpers need to be included into the <strong>Controller</strong> class. To avoid causing confusion when your helpers potentially conflict with our instance methods, we use an _ to disambiguate. As long as you don‘t begin your helper methods with _, you only need to worry about conflicts with Merb methods that are part of the public API.
before is a class method that allows you to specify before filters in your controllers. Filters can either be a symbol or string that corresponds to a method name to call, or a proc object. if it is a method name that method will be called and if it is a proc it will be called with an argument of self where self is the current controller object. When you use a proc as a filter it needs to take one parameter.
after is identical, but the filters are run after the action is invoked.
before :some_filter before :authenticate, :exclude => [:login, :signup] before :has_role, :with => ["Admin"], :exclude => [:index, :show] before Proc.new { some_method }, :only => :foo before :authorize, :unless => :logged_in?
You can use either :only => :actionname or :exclude => [:this, :that] but not both at once. :only will only run before the listed actions and :exclude will run for every action that is not listed.
Merb‘s before filter chain is very flexible. To halt the filter chain you use throw :halt. If throw is called with only one argument of :halt the return value of the method filters_halted will be what is rendered to the view. You can override filters_halted in your own controllers to control what it outputs. But the throw construct is much more powerful than just that.
throw :halt can also take a second argument. Here is what that second argument can be and the behavior each type can have:
throw :halt, "You don't have permissions to do that!" throw :halt, render(:action => :access_denied)
throw :halt, :must_click_disclaimer
throw :halt, proc { access_denied } throw :halt, proc { Tidy.new(c.index) }
:only<Symbol, Array[Symbol]>: | A list of actions that this filter should apply to |
:exclude<Symbol, Array[Symbol]: | A list of actions that this filter should not apply to |
:if<Symbol, Proc>: | Only apply the filter if the method named after the symbol or calling the proc evaluates to true |
:unless<Symbol, Proc>: | Only apply the filter if the method named after the symbol or calling the proc evaluates to false |
:with<Array[Object]>: | Arguments to be passed to the filter. Since we are talking method/proc calls, filter method or Proc should to have the same arity as number of elements in Array you pass to this option. |
Filter: | <Array[Symbol, (Symbol, String, Proc)]> |
params[:action] and params[:controller] have been deprecated as of the 0.9.0 release. They are no longer set during dispatch, and have been replaced by action_name and controller_name respectively.