Good design and flow for PHP - retain form values after submit

I've been searching for this topic on SO and it's quite a headache not finding one.

I had developed a website for some time already and found that the current problem is that after postback, if the submission has any error and the user is redirect back to the form, the form values are all gone.

Is there a good way/flow/design to implement such that开发者_StackOverflow社区 after postback the values are retained? Also I need to consider default values, values from database and the values from postback - so which one takes priority?

In addition, I wish to follow Post-Redirect-Get and use back the same form.

What I had thought of was:

1. Identify each form with a unique ID
2. When submitted, save all data into the Session using the form's unique ID
3. When the form is requested again, show the values from the form.
4. If submitted successfully, clear the data in session.

Here's my usual workflow:

After a POST fails I output form right away without redirecting to the initial form page. This is very easy to accomplish with any decent template system. You can then re-populate the form with the POST'ed data.

If the form is tied to a view (as part of an MVC pattern) you can initialize default values and load models from the database (to populate drop-down menus, etc.) - reuse the entire display / fronted logic.

If the current code base is using a redirect you can simply include() the desired form/view file at a serendipitous point in post-back processing.

So how does it work? In a nutshell:

• Define initial default values & user selection choices from model, database & configuration.
• Override any defaults with user-submitted $_POST data.
• Sanitize output
• Repeat until user input is validated.

The first answer has it nailed - if the post fails validation, regenerate the form/edit page with error messages, so the user can correct them and resubmit. (Don't expect them to press the "back" key).

There is a further tweak I would like to add.

When the post passes validation and the database has been updated, then redirect the browser to a page to show the data just updated. This achieves three good things.

a) If there was a problem updating the database, this will show the data on the database, not what you had left in the variables, so the problem will be very clear in testing.

b) Showing the data from the database gives the user confidence that things did happen as they intended.

c) If the user clicks a link away from this page and then uses the back button to return they will get the data shown again, not the question about resubmitting the data. This is more what the user expects, and will avoid double updating of the database.

Note - you must redirect with care. The referer variable will tell you the site the user actually has on his browser window. If he is using an SSH tunnel this may not be what you expect.

Ian

If the data is small enough (what, under 4k for cookies?), stuff it into a browser cookie so you don't have to store anything until it your script can validate every field.

As for defaults, user-input should always take precedence, otherwise your defaults will keep overwriting if they enter anything that doesn't validate.

A couple of advantages to using the cookie approach and redirecting to a GET form:

1. you avoid the "data must be resubmitted to continue" messages of immediately displaying the correction form after the POST
2. it's common for users to click the back button without thinking when they see an error, the cookie lets you pre-populate the form until the successful submit happens (or whatever expiry you put on it runs out) which is much more intuitive