I have the same problem. I think your question is a duplicate of Rails validation over redirect (and also duplicated more recently by custom validations errors form controller inside other parent controller rails 3.1).
The problem with the above solution by Pan Thomakos is that if VideosController#show
has more than a non-trivial amount of code in it then you would not be able to render from the videos/show
template without violating the DRY rule. Here's a related discussion.
This post from Ryan Bates of Railscasts fame suggests that you could store @video
in the flash to persist it across the redirect; however when I try to do that, it comes out the other side as an instance of the right class, but it doesn't have any of the superclasses you'd expect - most importantly ActiveRecord::Base
. At first I thought maybe his advice was simply out of date (it was written in 2006). However, one of the answers to Rails validation over redirect written in October 2009 advocates the same approach, albeit via a custom clone_with_errors
method which takes a shallow copy of the model instance in order to avoid issues with deeper objects. But even with that approach, any methods which rely on superclasses don't work. I'm guessing this is a consequence of the object being serialized into the flash and then deserialized out of it.
I found a page written in 2007 which advocates against storing model object instances in the session.
I also found a good argument in the formtastic google group pointing out that redirecting on validation failure is not the Rails Way, and probably a bad idea. But this still doesn't provide a good solution in the case where multiple controllers are involved. Perhaps Cells could be used to solve the DRY issue mentioned above.
Otherwise I guess the only answer is to stick with persisting simple data like object ids, error message strings, and so on.