SitePoint Sponsor

User Tag List

Results 1 to 14 of 14
  1. #1
    SitePoint Evangelist
    Join Date
    May 2007
    Location
    Montreal
    Posts
    408
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Retain Form Data

    Hi,

    Is there a simple function or snippet of code that can retain all form data?

    I have a form and want to retain data on error, so i am wondering if there is a simple and smarter way of doing it.

    Thanks

  2. #2
    SitePoint Enthusiast
    Join Date
    May 2003
    Location
    Barbados
    Posts
    37
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What do you want it to do?

    I'm assuming you mean that if the user submits the form incorrectly then the data is still present in the form fields while maybe an error message shows up to alert the user that they submitted the form incorrectly?

    Otherwise, if you simply want to store what was submitted by the form then you may either store it into a database (if you want to store/save the data on a longterm basis) or in an array/session/cookie (if on a more temporary basis)

  3. #3
    SitePoint Evangelist
    Join Date
    May 2007
    Location
    Montreal
    Posts
    408
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Spike0909 View Post
    What do you want it to do?

    I'm assuming you mean that if the user submits the form incorrectly then the data is still present in the form fields while maybe an error message shows up to alert the user that they submitted the form incorrectly?

    Otherwise, if you simply want to store what was submitted by the form then you may either store it into a database (if you want to store/save the data on a longterm basis) or in an array/session/cookie (if on a more temporary basis)
    Yes, its for retaining data when user submits information incorrectly.

    I have the error message working fine, and validation of data.
    But what i was wondering was the best way to retain the data in the form when user has an error in the page.

  4. #4
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Store the values in a session variable. When you re-load the form page, check to see if that session variable is there. If it is, then fill the form fields with the values in the session. If you have elements besides text or textarea fields, such as radio buttons, checkboxes or dropdown lists, I suggest you put together some functions to handle generating those elements with the proper selected values if needed.

    When you place the session variables back into text fields or textarea fields, run them through the function htmlspecialchars() first, to guard against XSS attack and to make all markup and attributes in your document valid.

  5. #5
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Location
    edge of nowhere
    Posts
    74
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Kinda like this. It's written in a hurry in this editor so excuse the lack of formatting.

    PHP Code:

    <?php
    if(isset($_POST){
    //process here

    if(/*is valid*/){

    //do stuff
    exit();

    }else{

    $_SESSION['post'] = $_POST;

    }
    //is valid

    ?>


    <form>
    <input type="text" name="foo" value="<?php echo htmlentities($_SESSION['post']['foo']); ?>" />
    </form>
    Programming boils down to three things: fast, good and cheap.
    Please pick two.

  6. #6
    SitePoint Evangelist
    Join Date
    May 2007
    Location
    Montreal
    Posts
    408
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the advice on the htmlentities()...
    helps a lot

    I found a site, www.webformfactory.com that will create a php form with any HTML form you upload.

    Anyone know of any software that can do this, perhaps one you can download instead? or in dreamweaver

  7. #7
    SitePoint Enthusiast
    Join Date
    May 2003
    Location
    Barbados
    Posts
    37
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I disagree with using session variables because you need to remember to unset those variables hence making them more difficult to use than simply using the $_POST variables.

    Here's my sample of what I mean:
    PHP Code:
    <?php
    if(isset($_POST['Submit']){
      
    $foo mysql_real_escape_string($_POST['foo']);
      
      
    //Process information i.e. store it in a database or whatever

    }else{ //Beginning of else statement
    ?>

    <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post">
    <input type="text" name="foo" value="<?php echo htmlentities($foo); ?>" />
    <input type="submit" name="submit" value="Submit" />
    </form>

    <?php
    // Ending of else statement
    ?>
    Of course, you can take this further by outputting inlinewarnings to let person's know exactly what they did wrong when they tried to submit and why the information is showing up again. That helps to make your application more userfriendly which is indeed a necessity.

  8. #8
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you are posting back to the same page that the form is on, of course there is no need to store them that way. If however you post to a separate page that on error re-directs with the proper error message, then yes a session is the best way. Storing it in a database is a waste of resources if the data isn't yet ready to commit for long term storage.

  9. #9
    play of mind Ernie1's Avatar
    Join Date
    Sep 2005
    Posts
    1,252
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    //it's $_POST['submit'] not $_POST['Submit']
    //however this is not efficient.
    //try this:
    <?php
    $foo 
    = isset($_POST['foo']) ? mysql_real_escape_string($_POST['foo']) : false;
    //insert...redirect
    ?> 
    <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post"> 
    <input type="text" name="foo" value="<?php echo htmlentities($foo); ?>" /> 
    <input type="submit" name="submit" value="Submit" /> 
    </form>
    my mobile portal
    ghiris.ro

  10. #10
    SitePoint Enthusiast
    Join Date
    May 2003
    Location
    Barbados
    Posts
    37
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hammer65: I assume you mean if the <form> tag was declared as follows?

    Code:
    <form action="form.php" method="post">
    Even then though, wouldn't the $_POST variables be sent to form.php file anyway? I guess you mean that if an error occurred then you'd want to redirect the user back to the .php file with the form on it but why not just include it in form.php? When you think of it, it's usually cumbersome to submit a form to another page when you want to use validation.

    Ernie1: You're right...even though php is case-insensitive IIRC.
    However, isn't that simply a shortened version of writing an 'if-else' statement? Also, isn't it harder to debug hence less effecient?

  11. #11
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It can be beneficial to separate the form from the submit page for a number of reasons. I use this technique for everything but search pages.

    On one level, separating the code makes both scripts maintainable and testable separately. It also makes the system as a whole easier to debug and follow.

    Also when inserting data into a database or sending mail for instance, you don't want double submissions. If you use post, and post to a different page, you can use HTTP headers to tell the browser not to cache the submission page. When the submission page is finished with it's task, or when there is an error and there is a re-direct, the browser back button or a refresh will not cause another submission.

    You transmit the error message back to the form page via the URL or session and save the contents of the submission in a session variable. When you come up on the form use htmlspecialchars() to process the input (including the error message) and insert the values into the page.

    Sometimes it's good to have a page perform multiple actions based on input, other times it's best to divide the task up into separate scripts.

  12. #12
    SitePoint Enthusiast
    Join Date
    May 2003
    Location
    Barbados
    Posts
    37
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I get what you're saying but it still seems cumbersome when a simple if-else can solve it instead of dealing with more session variables or header redirects.

    Also find it wierd that you do that for everything but search pages since search pages are often the most complex.

    I guess it's your personal preference?

  13. #13
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Search pages are usually paginated and you should always provide the search box on the result page, in case the user wants to do another search. Using get for searches is also recommended as the user may want to be able to use the back button. It's a totally different situation.

    Unless you are using templates, a page with a large form and the submission code on it can get rather long. When you are doing work on it, you end up doing a lot of scrolling. Separating it can make it easier to follow and troubleshoot. The submission code can also handle edit and delete options for records without a high line count, if it is separate from the form code.

  14. #14
    SitePoint Enthusiast
    Join Date
    May 2003
    Location
    Barbados
    Posts
    37
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And pagination is no simple code...so you see...it is complex. All other form submissions are is if-else statements.

    What is the real issue with the back button anyway? Most modern browsers detect that and alert the user and don't you program so your code alerts the user to possibly undesired duplicate entries?

    Including edit and delete options is nice but if you'll go that far...it's easier and more sensible to make a class and go the object-oriented approach.

    That said, we simply have different methods and it seems it works for both of us. As I'm sure we both know, there's no one way to solve a problem in programming at all. So we just have our different ways it seems.


Bookmarks

Posting Permissions

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