views:

48

answers:

3

I have a main form with a lot of inputs. The forms action is set to a php file. After submitted the php-page shows up with all the inputs that the user typed into the form. The user has to re-check everything and hit an 'approve' button! The problem is, I don't know how to do this...

I want to eventually put all data into a MySQL database, but only after hitting approve, not submitting the form!

Is there a way to 'recall' the php script after clicking the button 'approve'?

How is this done? I mean, I don't want to write information to the MySQL database, and then the user regrets and DOESN'T hit 'approve' and then the data is already in the database.

Thanks!

Just let me know if you need more input (I will then update the question)

+5  A: 

One way to accomplish this is rewrite every value that was just submitted into the approval form in the form of html hidden inputs. Like this:

<form name="approval" method="post>
    <input type="hidden" name="firstname" value="<?php echo htmlspecialchars($_REQUEST['firstname']); ?>" />
    <input type="hidden" name="lastname" value="<?php echo htmlspecialchars($_REQUEST['lastname']); ?>" />
    ...
    <input type="submit" value="Approve!" />
</form>

Others have suggested storing the values in the users session. If you choose to go that route, be careful about user's who like to work with multiple browser windows open at the same time. Their different forms will share the same session and depending on what order they choose to submit forms in, you could end up with some crossed wires if your code is too naive. One way around this is to generate a unique key for each form and pass it around from page to page. This of course gets messy which is why I prefer the hidden form field approach.

Another pitfall related to the session approach is the PHP's default session implementation uses the local filesystem to store session data. This breaks down when you have redundant web servers. You can, of course swap the default file based session implementation for something more sophisticated (based on memcached perhaps). But again, this is just more complexity. Why not avoid the complexity and stick with hidden form fields?

Asaph
+1, but typo: missing `)` in htmlspecialchars call.
bobince
+1 for explaining the session problem.
Svante
@bobince: thanks fixed
Asaph
+1  A: 

You can store the information in one of two ways: using the session or as hidden form inputs.

Using a Session It would make a lot of sense to use the session in this case. So, when the first form is submitted, start a session with the user and save all the values in it. Then, the confirmation page simply shows the data. When the user hits "approve", this triggers your script to store the information that is already in the session. This is a well-known method for persisting information between requests.

Using a Hidden Form As you write out your "approve" page, you could also write hidden form inputs along with your displayed confirmation data. Adding a new field to indicate that the user has approved this data, your script will only write to the database when it sees this confirmation value.

Without knowing much more about your application, I'd prefer using sessions in this case.

jheddings
which is more reliable?
Camran
It depends on what you mean by "reliable." Sessions can timeout based on server configuration (something like 15 minutes). Hidden forms could be by-passed by simply sending the "confirm" value with the first posting.
jheddings
One drawback of using hidden inputs is that you cannot easily handle things like file uploads. Also, if you are handling large form inputs, you will have to send that data back and forth to the client each time, which can be wasteful.
jheddings
Sorry, another thought... If you have forms that spans multiple pages, it can be difficult to allow the user to move back and forth through the pages using hidden inputs. In general, sessions were designed to handle what you are trying to do: remember state between requests.
jheddings
A: 

You could store all the information in a session first. Then make your calculations, and have the user approve the information. Write them from the session into the database.

Pekka