In essence, what you is a state problem. HTTP is a stateless protocol, which means that no transaction remembers anything about the prior transaction. However, there are a couple of ways to "fake" state retention in a CGI script.
- When your user submits this data, you have the files saved to temp files and the text fields in to scalars ($foo and $baz). Untaint $foo and $baz, slap them in a database. Add the names of the temp files to this database. In the second HTML page (which fuzzyping rightly directs to CGI::Application to handle) plant a hidden form field with the key to those database entries. Have a submit button with a "continue" value, and if the script recieves a continue vale it checks the hidden parameter for the database key, and pulls out all the right info to do appropriate things with. If not, it redirects to the correct page, and deletes the entry in the database and the temp files.
- Doing the above but using cookies to maintain state.
- Since you are presenting the user with formatted data, embed that formatted data into a hidden form field on the page, and have a submit button with a "continue" value. If the script recieves the "continue" value, it checks the hidden param for the preformatted data and does appropriate things.
I'd go with #1. It's a little more work than #3 but is cleaner, scales better, and is more readily extensible. #2 is really just there for completeness, as cookies are a bad fit for this problem UNLESS this is a largeish website with a user logon already in place. If this is the case, then the user already has a cookie, and you can leverage that for state maintenance.
Cheers,
Erik
Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet
| [reply] |
| [reply] |
I'm not quite sure what you're trying to present to the user in the interim, but there's no reason why you can't simply include another SUBMIT button, albeit with VALUE="Continue". Assuming you're keeping track of your user session via cookies or hidden values, this should fulfill your requirements (although I'm not entirely clear on them). You might want to look at CGI::Application to help handle your "run-modes".
Something else that might help you out is this technique from Merlyn.
HTH!
-fp
Update: s/shouldn\'t/should/ | [reply] |
What you are trying to do wont work because as stated above the HTTP protocol is stateless. But what is actually you problem is this particular case is that most browsers will timeout eventually, and that is usually before the user makes up their mind about what to do.
Therefore you need to have your state information embedded in the next request (this gives a lot of problems securitywise, but that is a whole other matter). And this also means that you have to cut up your processing into two segments, one where the user gives you the data and one where she/he verifies it.
T
I
M
T
O
W
T
D
I | [reply] |
