Forum: Ruby on Rails Best practices advice: Redirecting-to vs. rendering errors

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bb4bdf2b184027bc38d4fb529770cde5?d=identicon&s=25 Wes Gamble (weyus)
on 2007-01-15 18:52
All,

I'm looking for advice on the best way to handle error displays.

I always redirect to the next action when an action succeeds (see p. 432
of AWDWR for why).  That's fine.  This ensures that when the "Back"
button is used (at least in IE), a user will never be re-prompted to
POST, assuming that the redirect target is always retrieved using GET.

However, when an error occurs on a form POST, you probably need to
re-display the entry form with various error messages.  If you redirect
to the entry form, you will almost certainly end up putting your
erroneous object on the session (either by setting a session or flash
attribute) in order to have access to it again on the redirect request
to display the error page.  Sometimes, it is impossible to put such an
object on the session because it is too big.  Also, you end up
cluttering up the session for one request _just_ to display errors.

However, if you simply render the display page, then your erroneous
object is still available and you can just display it.   But then you
re-introduce the "POST-render" issue that will cause use of the "Back"
button to prompt a re-POST (at least in IE).

There seem to be two ways to go, and I'm looking for advice on which is
better:

1) Redirecting to an error, but using a temporary object to hold just
errors (when necessary, which is more or less only when you are dealing
with attempting to update a _big_ object) and setting that on the flash.
This may make your view need to be a little smarter, but it's not a big
deal.

2) Re-rendering the form on error, and, in order to handle the "re-POST"
prompting when hitting the back button, removing this POST request from
the history (via JS) when the page is rendered.  This makes the code
much simpler in the controller (no need to create a container for errors
in the error handling code in the controller as in #1).  A side-effect,
of course, is that error page display would be removed from the app.
page history.  But, I'm thinking that would be ok.  Obviously, JS needs
to be enabled in order to do this.

I'm leaning towards #2 so far.

Thoughts?

Wes
Bb4bdf2b184027bc38d4fb529770cde5?d=identicon&s=25 Wes Gamble (weyus)
on 2007-01-15 19:14
Wes Gamble wrote:

> 2) Re-rendering the form on error, and, in order to handle the "re-POST"
> prompting when hitting the back button, removing this POST request from
> the history (via JS) when the page is rendered.

Duh, I can't modify the history programmatically.  Sorry.

Despite that, any thoughts on this?

Thanks,
Wes
This topic is locked and can not be replied to.