$_POST and refresh/going back to a page.

[Chousho]

I'm working on a way for users to add content to a database.
I have a form that has an action to itself, and checks if $_POST is set.
If it isn't, it displays the form. If it is, it adds to the database and displays a "text submitted" message.

It works great except for a few things. If the user refreshes, it will pop up with a box saying something along the lines of, "do you want to POST again". This also happens if they go back a page, depending on the script.


So what's a way around this? I noticed VB and other software don't have this happen.

[auricle]

You could have the script redirect to another request if the user-submitted data is valid. That request could display the 'success' message.

[Dan Grossman]

So what's a way around this? I noticed VB and other software don't have this happen.

VB redirects you to a new page immediately after processing the post. If you hit refresh, you're refreshing the URL you were redirected to, which you didn't post anything to. That's the simplest solution.

Another way to handle it is to set some flag in the user's session when they are shown the form. When you receive a form post, check that this flag is set in the session. If it is, process the post and remove the flag. If it isn't, it's a duplicate post, so you can ignore the data and display an error or redirect.

[cranial-bore]

I have functions, set_sessionMessage() and get_sessionMessage(), which allow you to give responses to form actions after a redirect (thus clearing the POST data).

The general logic may be something like this:

1. Show form
2. On submit, error check, show form populated with user data on failure
3. If valid data INSERT, set_sessionMessage, redirect back to same page
4. If get_sessionMessage() display it

So I use 1 script for error messages, sucess messages and to process the form.
The script just looks for a form submission, or a previously stored sessionMessage to display. After successful submission the user can refresh or go back without reposting the form.

get_sessionMessage also REMOVES the message from the session after returning it, so that it isn't displayed the next time the page is loaded (unless another form submission is made).

It's also a good idea to draft off all your long winded form validation, processing and presentation logic to separate classes/functions so you don't end up with a monster procedural script with 1000 lines of code. Very hard to maintain and understand. Also avoids having huge if, else() blocks.

[Chousho]

Thanks for the ideas, all! Just some notes

Another way to handle it is to set some flag in the user's session when they are shown the form. When you receive a form post, check that this flag is set in the session. If it is, process the post and remove the flag. If it isn't, it's a duplicate post, so you can ignore the data and display an error or redirect.

This would be ok for inserting data into the db, but I was also hoping for a cleaner user experience as well. While it would work, would you still get that ugly popup about POST data?

I have functions, set_sessionMessage() and get_sessionMessage(), which allow you to give responses to form actions after a redirect (thus clearing the POST data).

The general logic may be something like this:

1. Show form
2. On submit, error check, show form populated with user data on failure
3. If valid data INSERT, set_sessionMessage, redirect back to same page
4. If get_sessionMessage() display it

So I use 1 script for error messages, sucess messages and to process the form.
The script just looks for a form submission, or a previously stored sessionMessage to display. After successful submission the user can refresh or go back without reposting the form.

get_sessionMessage also REMOVES the message from the session after returning it, so that it isn't displayed the next time the page is loaded (unless another form submission is made).

It's also a good idea to draft off all your long winded form validation, processing and presentation logic to separate classes/functions so you don't end up with a monster procedural script with 1000 lines of code. Very hard to maintain and understand. Also avoids having huge if, else() blocks.

Hmm, this is interesting. As I'm moving into doing this all in OOP from what was previously procedural I'm a bit curious. As of now I have a class that handles manipulation and creation of the data. In this class I have a method that displays the form and is basically a self contained page, and I know it's a horrible way to do it, but I'm also not too familiar with templating (and I'm a bit hesitant about using an outside template engine until I understand how it work better, in which I would rather just write my own eventually, anyway).

[byron3@earthlink]

I'm working on a way for users to add content to a database.
I have a form that has an action to itself, and checks if $_POST is set.
If it isn't, it displays the form. If it is, it adds to the database and displays a "text submitted" message.

It works great except for a few things. If the user refreshes, it will pop up with a box saying something along the lines of, "do you want to POST again". This also happens if they go back a page, depending on the script.


So what's a way around this? I noticed VB and other software don't have this happen.

The way around this is to use a form handler page. Instead of trying to send the post data to the same form, send it to a form handler. The handler page does the grunt work and writes messages (either success or failure and failure cause to a session variable). The the handler script then uses header() to send you back to the referring page. You break your code up into more manageable chunks and you separate your database code from the form code.
The message you get on refresh states that the request contains post data and would you like to resubmit the data. With a form handler this never occurs because the post data is sent to a form handler and the form handler sends you back full circle minus post data.