Understanding before and after_filter

Question

I have the following code right after my controller class declaration

  before_filter :load_form, :except => [:create, :update, :delete]
  after_filter :load_form, :only => [:create, :update, :delete]

  def load_form
    @severities = Severity.all
    @severity = Severity.new
  end

I get the list of severities when the page loads just fine, meaning that the before_filter is working. However after calling a method such as create the list of severities always comes back as nil. I think I am probably just missing some fundamental thing about filters. Can anyone help me understand why the after_filter does not work?

Solution

If you were expecting to see variables in your view that were assigned in your 'after' filter, that won't work because the filter is not executed until after your view has been completely processed.

Comments

[Jason Yost]

ahh, that makes sense, so what filter should I use to be able to see the variables in my view?

[Steve Jorgensen]

Well -- before, or around. What was the reason you thought you should use an after filter?

[Jason Yost]

I thought since I was setting the @severity object to new that if I used before_filter I would never be able to save since the object would always be set to new before I could actually access the parameters to save it.

[Steve Jorgensen]

Why do you think that assigning the value of @severity is something that should happen in a 'before' filter rather than in the action method? In fact, unless there's some reason that every (or almost every) action needs the entire list of severities, there's not much reason to assign @severities in a filter either.

[Jason Yost]

The views are rendered via ajax, so there is a form to create and update as well as the list of severities on a single page. each action needs to specify the new and collection of severities otherwise a null exception is thrown. Rather than declare each in every action I would rather keep things DRY and have those values set on each action by using a filter.

[Steve Jorgensen]

That makes sense for @severities then, but if @severity is handled differently in different actions, it's probably best to simply set it in each action or invoke a method to do that, and do it from within each action. It's easy to go overboard with filters, and end up with code that's insufficiently explicit at the expense of trying to be DRY.