How should one have several different controller' actions set a common instance variable for use in templates but after the action runs.
In other words, I want this to work in my application_controller.
class ApplicationController < ActionController::Base
after_filter :set_something_common
def set_something_common
# All controllers' actions have queried the DB and set @foo for me...
@bar = some_calculation_on(@foo)
# ... and all templates expect @bar to bet set.
end
end
This does not work because after_filter
runs after rendering. Fine. But what is the correct pattern?
Again, it is important that set_something_common
runs after the action because those actions do case-specific things; but they all set @foo
.
None of my ideas seem ideal:
- Call
set_something_common()
towards the bottom of every action that needs it. Refactor all controllers' case-specific code into
case_specific_code()
and force them to run in order:before_filter :case_specific_code, :set_something_common
Subclass
application_controller
and redefine theindex
method.
Any thoughts? Thanks.
Edit: Matthew's response prompted me to clarify:
Several controlers' index() all do pagination, each taking parameters @offset
and @limit
(via a global before_filter
) to view data slices. Great. Now I want a common method to compute a RESTful URL for the "next slice" link. I was encouraged to see that url_for()
generates a URL returning to the same resource, so I tried:
def set_something_common # really called set_next_url, truth be told
@next_url = url_for(:offset => @offset + @limit, :limit => @limit)
end
I will try monkey patching Fixnum, so I can do something like @offset.next_url_for(self, @limit)
from the template, but I'm not sure if it will work. Come to think of it, if I am going to modify the templates, then I may as well set up an application helper. I'm still not sure what the best solution is.
Update: Accepted answer is "use a helper."
Thanks for the updates from everybody. I learned my lesson that helpers, like global variables, are there for a reason and not to be eschewed when they are plainly beneficial and succinct.
Use
<%= do_some_calculations(@foo) %>
inside your templates. That is the straight way.Firstly, you don't want to try to insert code "between" a controller action and a template rendering. Why? Because you want the controller action to have the freedom to choose what sort of response to give. It could return XML, JSON, headers only, a redirection, nothing, etc. That's why after filters are executed after the response has been rendered.
Secondly, you don't want to monkey patch
Fixnum
. I mean, maybe you do, but I don't. Not often at least, and not unless I get some totally wicked semantic benefits from it, like being able to say3.blind_mice
. Monkey patching it for a random use case like this seems like a maintenance headache down the road.You mention refactoring out all the controllers' case specific code into a before filter and running them sequentially. Which brings up to my mind...
@foo
is the same in every case? If that's the case, then one before filter would work just fine:That's a totally legit approach. But if @foo changes from controller to controller... well, you have a few more options.
You can separate your before filters into two halves, and customize one per controller.
But you know, if it's a simple case that doesn't need database access or network access or anything like that... which your case doesn't... don't kill yourself. And don't sweat it. Throw it in a helper. That's what they're there for, to help. You're basically just rearranging some view data into a form slightly easier to use anyway. A helper is my vote. And you can just name it
next_url
. :)I would have a method on
@foo
which returns a bar, that way you can use@foo.bar
in your views.<% @bar = @foo.bar %>
#if you really don't want to change your views, but you didn't hear this from me :)