HttpResponseRedirect vs render_to_response after form?

[mw]

Hello,

I know that the documentation says NOT to use HttpResponse and to use
HttpResponseRedirect instead after a form entry, but what about just
using render_to response?


In other words, is something like this fine to use after a form
submission?

if form.is_valid():
form.save()
return render_to_response('thanks.html', {'foo':True})
else:
form = submitForm()
return render_to_response('submit.html', {'form':form})

I'm confused.

Thanks in advance,
mw

[Karen Tracey]

render_to_response is simply a shortcut that returns an HttpResponse.  So whatever the doc says about (not) using HttpResponse after a successful form POST applies identically to render_to_response.

Karen

[Scott Moonen]

Hi,

render_to_response has the same disadvantage in this case as HttpResponse (in fact, it produces an HttpResponse).

The reason for this is due to how HTTP and browsers work.  With your code below, on your "thanks" page, if the user clicks Refresh, most browsers will actually re-post the form that the user submitted.  Normally that is not a good thing.  Well-behaved browsers will ask users to confirm that they really want to re-post the form, but still you don't want your users to experience that.

However, if you return a redirect after saving the form, then the browser will load the new page, and any refreshes of that page will not re-post your form.

  -- Scott

On Tue, Aug 5, 2008 at 2:44 PM, mw <mwol...@gmail.com> wrote:

--
http://scott.andstuff.org/ | http://truthadorned.org/

[mw]

Thanks for all of the quick replies!

Oh my mistake! Gah I should have realized that it just returns the
HttpResponse.

So when you say that if it is saved then redirected, it wouldn't be a
problem, would that be something like this rough code?

if form.is_valid():
an_var = form.save(commit=False)
#check for some duplicates here

#
return render_to_response('error.html',
{'error':"We're sorry, "})
else:
#save the
data
an_announce.save()
return render_to_response('thanks.html',
{'announcement':True})

[James Matthews]

No because you are using render_to_response()

--
http://www.jewelerslounge.com
http://www.goldwatches.com/mens/cufflinks.html

[mw]

Ok, I gotcha on that, but
In the case of that code, though, a user that accidentally hit reload
wouldn't post twice if you had some type of duplicate checking before
saving. In that case, are there other reasons not to use
render_to_response? Since the duplicate post problem would be
handled, albeit maybe not in the most elegant way?

> > > --http://scott.andstuff.org/|http://truthadorned.org/<http://scott.andstuff.org/%7Chttp://truthadorned.org/>
>
> --http://www.jewelerslounge.comhttp://www.goldwatches.com/mens/cufflinks.html

[Karen Tracey]

On Tue, Aug 5, 2008 at 4:06 PM, mw <mwol...@gmail.com> wrote:

Ok, I gotcha on that, but
In the case of that code, though, a user that accidentally hit reload
wouldn't post twice if you had some type of duplicate checking before
saving.  In that case, are there other reasons not to use
render_to_response?  Since the duplicate post problem would be
handled, albeit maybe not in the most elegant way?

The browser warning is generally confusing to users, who for the most part have no idea what POST data is, and certainly have no idea whether your web site can handle duplicate POSTs properly.  So even if your web site handles it, structuring your views so that users may encounter that browser warning when clicking reload is not ideal.

Karen

[julianb]

On Aug 5, 10:06 pm, mw <mwolff...@gmail.com> wrote:
> In that case, are there other reasons not to use
> render_to_response?  Since the duplicate post problem would be
> handled, albeit maybe not in the most elegant way?

The user would still execute a POST, or submit form data, just to get
the "thanks" page. You can do it that way but it's not elegant. If
nothing gets changed in the database or so you shouldn't use POST.

[mw]

Great posts so far, thanks for all of the help!

Just so I'm clear, in the trials I've done so far the only time my
browser has asked to resend the post data was when I clicked reload on
the actual Thanks page. If I click back on the thanks page, then
forward again, it goes right back to the thanks page without the
browser asking to send the data twice and without a duplicate entry.

I know that the proper way would be to use the redirect, but it seems
as if this works fine for now. Other than end user considerations,
which seem to only come up for my basic messing around when I click
reload on the thanks page, are there other reasons to use the
redirect?

Thanks again for the great posts,
mw

[bruno desthuilliers]

On 5 août, 23:24, mw <mwolff...@gmail.com> wrote:
> Great posts so far, thanks for all of the help!
>
> Just so I'm clear, in the trials I've done so far the only time my
> browser has asked to resend the post data was when I clicked reload on
> the actual Thanks page. If I click back on the thanks page, then
> forward again, it goes right back to the thanks page without the
> browser asking to send the data twice and without a duplicate entry.
>
> I know that the proper way would be to use the redirect, but it seems
> as if this works fine for now. Other than end user considerations,
> which seem to only come up for my basic messing around when I click
> reload on the thanks page, are there other reasons to use the
> redirect?

This is a GoodEnough(tm) reason. You can bet users will do any kind of
unexpected things.