A potential solution (very rough!) to Rails ivars-in-views problem

gistfile1.rb

ActionController::Base.class_eval do
  def self.context(*actions, &block)
    contexts[actions] << block
  end

  def self.contexts
    @contexts ||= Hash.new {|h, k| h[k] = [] }
  end
end

class MyController < ApplicationController
  before_filter do
    contexts = self.class.contexts.select do |actions, context|
      actions.empty? || actions.include?(@_action_name.to_sym)
    end
    contexts.values.each do |procs|
      procs.each do |cxt|
        self.class.helper(&cxt) # so we can call from the view
        instance_eval(&cxt) # so we can call from the controller
      end
    end
  end

  def about
    foo # raises "from foo"
    bar
  end

  context do
    def foo
      raise 'from foo'.inspect
    end

    def bar
      raise 'from bar'.inspect
    end
  end

  context :nope do
    def foo
      raise 'from nope'.inspect
    end
  end
end

I don't think I like that one either. Don't understand why the Context needs to be its own class.

On Wed, Apr 11, 2012 at 3:51 PM, Justin Ko ***@***.*** wrote: @avdi @tenderlove has tried that: https://gist.github.com/2287133 Personally, I'd rather just stick with ivars instead of creating new classes. --- Reply to this email directly or view it on GitHub: https://gist.github.com/2357038

## Avdi Grimm http://avdi.org I only check email twice a day. to reach me sooner, go to http://awayfind.com/avdi

I agree, which is why I put them in procs.

Going to try this out sometime: https://github.com/jonleighton/focused_controller

If you want to have more fine-grained control over what's exposed to your views, does https://github.com/hudge/proffer help at all? It removes all instance variables from views and gives you an interface to expose only the variables you want as locals.