Best practices advice: Redirecting-to vs. rendering errors

Rails
1

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

2

Wes G. wrote:

  1. 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