That’s one of the chief reasons for the session… to persist parameters
between requests without using the URL. I used this method all the time
in
my old ASP applications. At least Rails makes it easy
More broadly, any other way to pass data between foo and bar, besides
sticking it in session?
I think the session is your only bet. Why not store the params in the
flash? That way you won’t have to worry about manually expiring it
like you would if you created your own session.
Use a before filter to pull the data into an instance variable from the
session if the session has the key. Then invoke this filter on any
methods
that have multiple entrypoints.
That’s one of the chief reasons for the session… to persist parameters
between requests without using the URL. I used this method all the time in
my old ASP applications. At least Rails makes it easy
Ok, but what would you do in the following common scenario:
#bar requires two parameters, bart and lisa. Normally, #bar is invoked
directly, by a POST request supplying it with those parameters. But
sometimes, you want to #redirect_to it from some other method, say #foo.
One option is to write a mechanism at the beginning of the method which
abstracts bart and lisa (e.g. assigns them to local variables) so that
the rest of the method is indifferent as to whether bart and lisa were
supplied by a direct POST or by passed in the session.
This is awkward and the result will be somewhat bloated imho.
Another option is to transfer all of #bar’s functionality to a new
method, #baz, that is ALWAYS invoked indirectly, by a #redirect_to, so
it ALWAYS looks for bart and lisa in the session. Then of course you
make the original #bar a thin wrapper that takes bart and lisa from
params, sticks them in session where #baz would find them, and
redirects_to #baz.
This latter one is more elegant, but I wonder if all those redirects
are really a Good Idea, considering performance issues and such.