Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 8 of 8
  1. #1
    New Coder
    Join Date
    Jul 2002
    Location
    Florida
    Posts
    60
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Disappearing form values

    I've run into this problem before but can't remember how I solved it. I'm using IE 5.5 and PHP 4.3.

    The problem is simple. The user submits a form with some HTML data on it, text boxes, etc. I then do some validatations and give the user a back button (using a little Jscript history there) to make corrections if anything is wrong, e.g., an incorrect phone number.

    But when the user returns to the previous page, all the variables are gone. That is, the form is blank! And it doesn't matter if the user uses my back button, or the browser's one. Now that's enough to piss off the Good Humor Man, especially if they've entered lots of data on the form!

    Also, this problem seems to come an go on different pages, with no rhyme or reason to it.

    So what to do? Perhaps store all the values as session vars, and then retrieve all of them in this case?

  • #2
    raf
    raf is offline
    Master Coder
    Join Date
    Jul 2002
    Posts
    6,589
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I've noticed the same behaviour. I think it has something to do with the webserver setting.

    If i jump back to a page when my PHP's are served by IIS, the values aren't there. When i do the same when i served them with Apache, the values are there.

    If it really bother you, you can use multipurpose pages.
    You post the page to istelf and do the formvallidation at the top of the page. If all values are valid, you redirect or perform a db-action or ...

    If some values are incorrect, you display the page again and you insert the value from the formcollection.

  • #3
    New Coder
    Join Date
    Jan 2003
    Location
    Tulsa, OK
    Posts
    69
    Thanks
    0
    Thanked 0 Times in 0 Posts
    In most cases, if you are filling out form fields on a .php document, if you have submitted the data and hit a BACK button to return to the fields, the cached page from before [the original fields you filled] expired and was re-processed through the PHP engine. I'm not sure how to prevent that, nor have I tried Apache filesystems.

    Yep.

  • #4
    Senior Coder
    Join Date
    Jun 2002
    Location
    ColoRockyz
    Posts
    1,649
    Thanks
    1
    Thanked 0 Times in 0 Posts
    Really bad websites don't know how to preserve the form fields...even major sites. Then, the user just moves on to another site.
    Try a session and use:
    PHP Code:
    <?php
    session_start
    ();
    header("Cache-control: private");
    ?>
    in the top of every page.
    Zoobie or not Zoobie...That is the problem.
    <body onUnload="flush( ! )">

  • #5
    raf
    raf is offline
    Master Coder
    Join Date
    Jul 2002
    Posts
    6,589
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Really bad websites don't know how to preserve the form fields...even major sites. Then, the user just moves on to another site.
    So 'really good' websites solve this with clientside caching ? And really good sites rely on javascript for such an important navigation-feature?
    And all that when they have the perfect tool to process the forms serversided and respond with a customized, validated and annotated version of the form that doesn't require a clientside action. (It really looks professional : "There was a problem but you need to click here (or use the back button if you have javascript disabled) and then look at field blabla")

    I never understood the big gain for users to be able to jump back in there history and see filled in forms.
    - Maybe people that design 'really good' sites where you have this fantastic feature, don't mind the privacy of there users as much as i do. (I remember an app i worked on to allow people to register themselves at the unemployent service. This ran at the centers on public machines. Pasword you only got by mail and the other tight security and all. And then John Doe just walked in, hit the backbutton a few times and browsed throug someone elses file. Real cool. Very 'good' site. They ended up making a special IE build without menus, disables alt <-- and all. )
    - Or maybe they like to invent complicated mechanismes to prevent users from submitting the same, validated, form more then once. (Run a search here and find out how many people started threads like "How to prevent people using the backbutton to resubmit a form etc", "I 've destroyed the session but the user can jump back and resubmit a form" ect . I suppose it will be dozens)
    - Or maybe they just are so good that they don't need to create realy database driven, dynamic or well designed sites, that display these nice 'insert next record ?' buttons (that bring you to a partially filled in form) over and over again (instead of using some smarter realy generic pages).

    Displaying the filled in formvalues is only usefull if the user didn't fill in the form correctly or if you want to recycle data the user inserted earlier (in other forms).
    For the first issue, i realy think you are better of using multipurpose pages where you post the form to itself and validate and proces it all in one page It is a far more secure, transparant and easier to maintain coding-practise. And it works for 100% of the users and is more userfriendly. You can perfectly 'echo' the valid values and remove and/or accentuate the invalid.
    For the second use : store the data in a cookie/sessionvariable/db/txt.

    Caching pages was never intended to return (parially) filled in forms. Relying on cached pages to recover formvalues is just bad practice.
    And caching all pages is just not a good recommendation. It should only be done on non-dynamically generated pages (and i frankly don't see why you should use php to generate those.) So i'd rather recommend
    header("Pragma: no-cache");
    on all dynamically generated pages.

  • #6
    New Coder
    Join Date
    Jul 2002
    Location
    Florida
    Posts
    60
    Thanks
    0
    Thanked 0 Times in 0 Posts

    What does this mean?

    Try a session and use:
    PHP Code:
    <?php
    session_start
    ();
    header("Cache-control: private");
    ?>
    in the top of every page. [/B][/QUOTE]

    I'm using sessions, but not in that way. I've decided to save the user's form fields in session vars, and then destroy them when everything is done. That last step is necessary so that, if they download the same form again for any reason, they won't see "Joe Blow" popping up again (they guy they previously entered on the form).

    But what exactly does this "cache control private" get you? That's something I've seen before. I'll do a little checking in the PHP on-line docs in the meantime.

  • #7
    New Coder
    Join Date
    Jul 2002
    Location
    Florida
    Posts
    60
    Thanks
    0
    Thanked 0 Times in 0 Posts

    That sounds interesting.

    >> For the first issue, i realy think you are better of using multipurpose pages where you post the form to itself and validate and proces it all in one page It is a far more secure, transparant and easier to maintain coding-practise. And it works for 100% of the users and is more userfriendly. You can perfectly 'echo' the valid values and remove and/or accentuate the invalid. <<

    But what happens when the page originally loads?

    If you do the validation on the same page, and it originally sees all those blank fields, you will never get the page to validate!

    I just don't see how you can put the validation functions on the same page the form is on, not unless there is some way of telling the page not to validate the first time it loads.

    Note: I do all my validations with PHP, not Jscript (as Jscript is too inconsistent and too much of a pain in the *** to work with for such).

  • #8
    raf
    raf is offline
    Master Coder
    Join Date
    Jul 2002
    Posts
    6,589
    Thanks
    0
    Thanked 0 Times in 0 Posts
    No.
    At the top of the page, you run a check like
    PHP Code:
    if isset($_POST['submit']) {
      
    your formprocessing etc
    } else {
      
    display the formheader or intoductiary text
      
    or the complete form

    the 'submit' is the name of the submitbutton, but you could just as well give it another name or check on a hidden formfield or so.

    An alternative is
    PHP Code:
    if isset($_POST['submit']) {
      
    your formprocessing etc
      validate everyhing 
    and add the errors all to one stringLike
      $error 
    .= "<br />Please fill in a valid phonenumber of format xxx xx xx";
      
    other check
      $error 
    .= "<br /> ...";
    }
    if (
    strlen($error) > 0) or (!isset($_POST['submit'])) {
      if 
    strlen($error) > {
         echo 
    "The following things need changing : "$error ;
      }
      
    the code to display the form.
      for 
    each formfield you have
      
    echo ("<input type=\"text\" value=\"" $_POST['name'] ."\" name=\"name\" />") ;

    Another alternative is to set a seperate errorvariable for each formfield (+ an extra that you increment for each error, so you only need to check for this value to know if you can go ahead after the validation, or if you need to resend the commented form). This way you can place the errormessages right in front/behind them and do some extra highlighting.


    If you google for it, you should find plenty of tutorials on it (like http://www.devarticles.com/art/1/220/2 <-- didn't read it, though)
    It's really something you should master to develop professional, userfriendly, guaranteed to work pages.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •