Page 1 of 1

Storing form values

Posted: Wed Sep 28, 2005 12:59 pm
by Ree
I usually handle form input this way: some form is on a form_page.php and POST goes to some other script (indicated in the "action" tag), for example, form_processor.php. If there was any problem with submitted data (empty/invalid fields), form_processor.php would redirect back to form_page.php and an appropriate message would be displayed. The problem is that upon redirection back to form_page.php, all form fields would be completely empty. I don't want the user to refill ALL the form fields if he made a mistake somewhere. I need the last submitted values stay after redirection. The only solution I can think of right now is sessions/cookies. Anything else you could recommend in this case?

Posted: Wed Sep 28, 2005 1:26 pm
by hawleyjr
Store your form variables into a session variable.


A rough example:

Code: Select all

//PROCESS PAGE
$_SESSION['FORM_VARS'] = $_POST;

//FORM PAGE

<input type="text" name="my_txt" value="<?php echo isset($_SESSION['FORM_VARS']['my_txt'])?$_SESSION['FORM_VARS']['my_txt']:'';?>">

Re: Storing form values

Posted: Thu Sep 29, 2005 3:04 am
by omega-systems
Using session you can lose other data (user can fill two forms simultaneously). Thats'why better use for processing and imagine same script. If user enter incorrect data or can't fill all fileds, you'll able to redisplay them.

Regards,
Michael.

Project Manager
Omega Systems Ltd
Email: info@omega-systems.biz
ICQ: 264962449
MSN: omega-systems@hotmail.com
AIM: OmegaSys Ltd

Posted: Thu Sep 29, 2005 3:17 am
by jayshields
imo sessions arent necessary in form processing. just combine the form processing script and the form display script into the same script using...

Code: Select all

<?php
if (isset($_POST['submit'])) { 
     //do something 
}
?>
to put the processing info into it. then it will keep all the post values because you will be redirecting to the same page. then just set the values of the inputs to the post values if they have already been set.

Posted: Thu Sep 29, 2005 4:10 am
by Jenk
jayshields wrote:imo sessions arent necessary in form processing. just combine the form processing script and the form display script into the same script using...

Code: Select all

<?php
if (isset($_POST['submit'])) { 
     //do something 
}
?>
to put the processing info into it. then it will keep all the post values because you will be redirecting to the same page. then just set the values of the inputs to the post values if they have already been set.
I've always had to use the following when using that exact criteria:

Code: Select all

<input type="submit" name="submit" value="Submit this form BEYOTCH!">
So I just use the name of a form element I am expecting to receive, insted. :p

Re: Storing form values

Posted: Thu Sep 29, 2005 4:25 am
by CoderGoblin
omega-systems wrote:Using session you can lose other data (user can fill two forms simultaneously).
Depends on how it is done. It is even more important to keep track of this now with tabbed browsers. I tend to give all my forms a unique identifier in the session. saving the form saves the information to the $_SESSION['form']['identifier]=values. On a sucessful save the form's values are emptied to prevent another save. This works quite well.

Re: Storing form values

Posted: Thu Sep 29, 2005 1:23 pm
by McGruff
Ree wrote:Anything else you could recommend in this case?
You shouldn't need redirects to make application controller decisions.

"Application controller" logic is something which decides the flow of the application based on the state of something or other. In a script which deals with a form submission, this means deciding if the submission is processable (all required fields were filled in, and all values have validated) or if the form should be redisplayed (they're not). You'd want to redirect after processing a submission to avoid the refresh-resubmit problem but you don't need to do this for the resubmit case - as you've found it creates a complication in that you have to persist the submission somehow in order to redisplay submitted values.

In OOP, I'd have a couple of request handler classes: one for form display which echo's back any POST values to the form (on first display POST is empty so you get an empty form) and one to process a valid submission.

Posted: Thu Sep 29, 2005 4:34 pm
by Christopher
The most obvious thing to do is to not submit form_page.php to form_processor.php, but instead have the form processor submit to itself. It needs to support init, submit and done states, but it is the standard way to do it. The usual setup is to have the form submit to itself and then redirect when done. That solves both the problem of retaining values and the Back button problem as well.

Posted: Thu Sep 29, 2005 4:46 pm
by Maugrim_The_Reaper
See McGruff's post...

Yes, you can submit back to the same file - but that does not make sense in all cases. For example I run an application which utilises a Page Controller and some basic MVC. I do not want the form to submit to the same page - but rather though a page controller to a separate command object...

Your case is only standard in limited circumstances...

Posted: Thu Sep 29, 2005 6:01 pm
by Christopher
I didn't say submit back to the same file or page as they don't mean much in this sense. I just said submit back to itself. I assumed that it would be some kind of controller that would have multiple states/commands. The implementation may vary.

Posted: Sun Oct 02, 2005 8:28 am
by Ree
Well, now I have the form display and data processing on the same .php script which allows me to redisplay submitted values in the form in case some of them didn't pass validation. This is all fine but I'm wondering if that 'POST' popup message in FF (when trying to refresh the page) is all right. Well, it asks if you want to resend the data, so I guess in my case it's fine.