I have a common failure page that I may need to render to upon failing
some test that occurs in an after_filter method.
I’d like to use the after_filter to take over the control of the
rendering, like so:
some_boolean = my_test
return render(:action => ‘disqualified’) unless some_boolean
@success_controller ||= controller_name
@success_action ||= action_name
return render(:controller => @success_controller, :action =>
In my action, if I do nothing unusual, then I expect to render to the
regular place. If I override @success_controller and/or
@success_action, then my action code can set up the success target.
Unfortunately, when I try to do this, I get a DoubleRenderError, which I
am sure is because the default render is already done in my action
before I attempt to do either render in the after filter.
Can this be done, or do I have to resign myself to only setting the
target in the after_filter, and then doing the rendering in the action
Can I just modify the response somehow in my after filter perhaps?
It looks like theoretically, at least, I could manipulate the response
body directly, which I think implies that I would be rewriting render to
Of course, it’s all a non-issue unless I could override the default
As it turns out, this is a non-issue.
But one way that you could get similar behavior would be to use
redirect_to in a before filter to respond to the test, whatever it is.
But in order to do this, you would have to always redirect_to every
action that the before filter was applied to, in order to get the before
filter to run.
Bottom line: It would be nice to have the ability to control/impact
rendering for an action outside of the action method itself.
In AWDWR v.1, p. 326, there’s an example of directly manipulating the
Has anyone else done this and can you vouch for the safety of the
I would have to process whichever template content that I wanted to
return and then put that result of that rendering into the response
Right, but I can’t control what is rendered into HTML/XML whatever
You can definitely modify the response in an after_filter: we have a
bunch of actions that produce xml, and an after filter that runs the xml
through an xslt filter (and the user only ever sees the resulting html)