in reply to Maintaining state with CGI.pm

You probably want to use is the self_url of CGI.pm; this returns a URL with all the state information that you need, so that you don't need to keep filling in hidden fields for old data. Just pass this as the ACTION method for your FORM, and that data is carried across. Note that you might have to play with adding and deleting values from the CGI instance variable so that they don't show up in this URL (for example, the page of 3 that you are on).

However, while this will work, as the amount of data entered increases, it is probably better to save the state of the data in files or databases on your end, using a unique session id that you then pass to further URLs, and upon completion of the last page, actually transferring all that data from files or databased into the final storage location that it will be stored in. This will be less prone to security faults as well, since only one state item (the session id) is passed.

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Replies are listed 'Best First'.
Re: Re: Maintaining state with CGI.pm
by MrCromeDome (Deacon) on Jun 01, 2001 at 00:36 UTC
    This post reminds me of a problem I am currently experiencing. . . If the state of the data is stored in a database, for example, and we pass around a session ID, how do we keep our database from becoming cluttered? How and when do we clean up the data left behind by no-longer used sessions? I imagine schedule a task to delete unused sessions, but by what criteria? Do we update the session timestamp every time a user performs and action, and delete only those sessions that haven't been touched in, for example, 30 minutes?

    Just curious ;) Thanks!

    MrCromeDome

[reply]
      You pretty much have the right idea. What you need to do if you go this route is have a sample selection of your users estimate the time it took to fill out the forms, and take a reasonable average and triple it. So if took the average user 15 minutes to do it, don't delete the entry for at least 45 minutes. Make sure to test this with remote users from a variety of connection types, and with users that have not filled out that form before, so that you get a good average. Of course, this time also could be a factor as determined by how many hits you get; if you expect that only one person a day will fill out a form, you probably can clear the database on a weekly basis. If, on the other hand, you get 100 people a minute filling the form, then yes, you want to minimize the time between database clearing.

      Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
[reply]
      Another method of cleaning out old entries is to do so every time you enter a new entry. (I use this a lot with shopping carts and the like.) Make sure every row in the table has a timestamp for when it was created and modified, then have a single DELETE statement remove all entries before a cutoff date. (half a day, 1 week, etc.)

      -franknmonk
[reply]
Re: Re: Maintaining state with CGI.pm
by nysus (Parson) on May 31, 2001 at 22:22 UTC
    Thanks.

    I toyed with the database idea last week but was missing the crucial piece of the puzzle you mentioned: having a unique session ID.

    I think I'm going to need to purchase another O'Reilly book on this topic and get much more familiar with this topic.

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar";
    $nysus = $PM . $MCF;

[reply]
      As merlyn has pointed out in the past, you can use the following code to generate a unique session_id. If you are going to use it for generating a file to save the CGI object in, be sure to use Taint checks. 
      use MD5;

sub generate_id {
    return substr(MD5->hexhash(time(). {}. rand(). $$. 'blah'), 0, 16)
+;
}

      [download]


      You may find this recent discussion relevant.

      -Lee

      "To be civilized is to deny one's nature."
[reply]
[d/l]

In Section Seekers of Perl Wisdom