Post-Redirect-Get Pattern in Rails

I’m curious as to the best way to implement this pattern
http://en.wikipedia.org/wiki/Post/Redirect/Get in my Rails application.
It’s really a must to make the user’s experience feel polished.

I haven’t seen many examples of it being used, I think it’s because of
the validation of the models. We need to keep the data the user
submitted in the form and show validation errors, so the we’d need to
store it somewhere to survive the redirect (flash could potentially be
used).

Here’s an example from the scaffolding.

POST /posts

POST /posts.xml

def create
@post = Post.new(params[:post])

respond_to do |format|
if @post.save
flash[:notice] = ‘Post was successfully created.’
format.html { redirect_to(@post) }
else
format.html { render :action => “new” }
end
end
end

So in this example I’d want the else to redirect_to the “new” action
instead of render, but where am I going to store the @post’s state.

Anyways I was hoping someone found a good solution to this in Rails but
I haven’t seen anyone talk about the pattern.

In the example you provided, the @post variable will
still be populated if the save fails, so the controller,
as it stands will be able to re-populate the form from
that. Why do you need a redirect?

The redirect on successful save is what makes the
pattern work – after the redirect the user is now looking at a GET
from “myapp.com/posts/113” and if she hits refresh, won’t
double post.

But if there’s errors and you need to post again,
I don’t see a problem just using the render as it’s written.

On May 27, 3:12 pm, James S. [email protected]

The wikipedia article uses the “fact” that a user may try to bookmark
that
page (after the create) and therefore not be getting the /posts/new but
rather /posts. imo, it’s a bunch of bollocks and redirect on success
coupled
with render on failure is much more simpler and therefore better for
you.
What kind of user would bookmark a posts/new page anyway?

On Wed, May 28, 2008 at 8:25 AM, JDevine [email protected] wrote:

the validation of the models. We need to keep the data the user

So in this example I’d want the else to redirect_to the “new” action
instead of render, but where am I going to store the @post’s state.

Anyways I was hoping someone found a good solution to this in Rails but
I haven’t seen anyone talk about the pattern.

Posted viahttp://www.ruby-forum.com/.


Appreciated my help?
Recommend me on Working With Rails
http://workingwithrails.com/person/11030-ryan-bigg

“If you make a fool proof application, only fools will use it.”

On Wed, May 28, 2008 at 7:43 PM, Frederick C. <
[email protected]> wrote:

pattern work – after the redirect the user is now looking at a GET
my Rails application.

format.html { redirect_to(@post) }

Rails but
http://workingwithrails.com/person/11030-ryan-bigg


Appreciated my help?
Recommend me on Working With Rails
http://workingwithrails.com/person/11030-ryan-bigg

On 28 May 2008, at 00:32, Ryan B. (Radar) wrote:

The wikipedia article uses the “fact” that a user may try to
bookmark that page (after the create) and therefore not be getting
the /posts/new but rather /posts. imo, it’s a bunch of bollocks and
redirect on success coupled with render on failure is much more
simpler and therefore better for you. What kind of user would
bookmark a posts/new page anyway?

Those damn clueless users! One of our internal apps is the one that
handles user authentication for the people that work for us; and one
person is in charge of creating these accounts. wouldn’t be surprised
at all if they bookmarked the new user page. I don’t have a particular
opinion about this redirect thingy, but it’s a slippery slope when you
start saying things like ‘what kind of user would do x’. It’s easy to
end up with an app that does exactly what you want, but not
necessarily what the end user wants

Fred

On 28 May 2008, at 11:21, Ryan B. (Radar) wrote:

“If you make a fool proof application, only fools will use it.”

Well there are a lot of fools out there, and it’s probably easier to
get money from them than from smart people so that might be a good
business model.
Joking aside, my point was that there’s a middle-ground and
bookmarking a page that you use often hardly seems outlandish (it is
after all the point of them).

Fred

So if I don’t want to loose the fool population with my app, what would
be the best way of adopting the post-redirect-get pattern on all post
operations?

Here’s my first try:

def new
@post = Post.new(flash[:post])
if flash[:post]
@post.valid?
flash[:post] = flash[:post] #Save it in the flash again to survive
a refresh
end

respond_to do |format|
  format.html # new.html.erb
end

end

def create
@post = Post.new(params[:post])

respond_to do |format|
  if @post.save
    flash[:notice] = 'Post was successfully created.'
    format.html { redirect_to(@post) }
  else
    flash[:post] = params[:post]
    format.html { redirect_to(new_post_path) }
  end
end

end

The only downside of doing it this way I can think of is that the cookie
stored session could overflow with a big enough post params. Then I
guess we’d have to switch to a different session store type (Memcache,
DB, or file based)

I 100% agree with the OP. In the playframework, you get this for free.
All you do is validation.keep() and params.flash() and do the redirect
and on a GET request it automatically fills in the user input and
errors. ie. you get no breakage of the back button which is very
annoying even for users who are experts. This project looks very very
promising but is only for rails 4 I think
https://github.com/tommeier/rails-prg

I find it sad when people go with “we don’t need to fix it” when it is
so simple to fix and many other frameworks like seam, playframework are
now ahead of rails in this aspect.

ruby invented the flash scope and playframework and seam stole it and
really used it to their advantage in a way better way than ruby giving a
much better user experience when it comes to the back button.

Dean

On 28 May 2008, at 14:56, James S. wrote:

So if I don’t want to loose the fool population with my app, what
would
be the best way of adopting the post-redirect-get pattern on all post
operations?

I’d store post.attributes rather than post. You don’t want to be
storing complex objects in the session if you can avoid it.

Fred

On Fri, Mar 28, 2014 at 3:21 PM, Dean H. [email protected]
wrote:

I find it sad when people go with “we don’t need to fix it”

I find it sad when people “reply” to six-year-old posts about a
rapidly evolving platform.

Sorrow manifests in many forms :slight_smile:


Hassan S. ------------------------ [email protected]
http://about.me/hassanschroeder
twitter: @hassan

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs