CGI.pm param not following post

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I have the follwing snip of code that is catching posts to the same page:

# this will load the params from the form post
sub loadParameters {

        my %requiredChecks;
        my $paramDescription;

        # grab the service param hash from the params passed in.
        %serviceParams = param("SERVICE_PARAMS");

        $serviceName = param("SERVICE_NAME");
        $serviceDescription = param("SERVICE_DESCIRPTION");

        $paramDescription = param("SERVICE_PARAMETER_DESCIRPTION");
        #now we have to load the parameter stuff
        if( $paramDescription )
        {
            $requiredChecks{"IS_REQUIRED"} = param("IS_REQUIRED");
            $requiredChecks{"IS_SELLER_DEPENDANT"} = param("IS_SELLER_
+DEPENDANT");

            $serviceParams{"$paramDescription"} = %requiredChecks;

            # now add the params to the master list for passing throug
+h.
            param("SERVICE_PARAMS", \%serviceParams);
        }
}
[download]

i thought that each post woudl allow me to append the SERVICE_PARAMS with any new values that are added however with each post only the current values for that post are shown. no historical inforamtion. will this manner work for passing page state information without using cokkies? what would be a good solution if this is not?

thanks in advance,
ken;

Comment on CGI.pm param not following post Download Code

Replies are listed 'Best First'.
Re: CGI.pm param not following post by Aristotle (Chancellor) on Jul 09, 2002 at 22:29 UTC
You have to save your data somewhere. Variables only contain the information for the current invokation of the program, and a CGI script gets invoked once per request. So what you see is entirely expected behaviour. For a simple solution you may want to look into DBM files tied to hashes as the DB_File module and others provide. Makeshifts last the longest.	[reply]
Re: CGI.pm param not following post by vladb (Vicar) on Jul 09, 2002 at 22:34 UTC
I have not heard a lot about ways to facilitate user sessions without having to resort to storing something on the client's PC. Say, normally a unique identifier is stored in a cookie in order to trace clients to session data on the server. An alternative to using cookies, you could explore other schemes of tracking users across the stateless protocol (HTTP) which literally runs the 'web'. This is to make use of your clients IP addresses. However, I would not advise this as a very 'solid' option. There are already a lot of Perl modules that were designed to help you in cases where you need to maintain a persistant client state (as in a session). Take a look at Apache::Session for example. Or, CGI::Session. Also, use CGI to retrieve form parameters and do other.. err.. CGI related stuff ;) _____________________ `# Under Construction` [download]	[reply] [d/l]
Re: CGI.pm param not following post by zaimoni (Beadle) on Jul 10, 2002 at 04:07 UTC
One time, I had to prototype that would be relatively stable, yet worked for WebTV web clients and hyper-secure IE/NS browsers. WebTV doesn't know what cookies are: all Set-Cookie headers are condemned to `/dev/null`. Ouch. PHP's session-handling functions and Perl's Apache::Session module are both ruled out by spec.... (I missed CGI::Session in this feasibility study.) IE and NS can be configured not to record cookies at all. I ended up prototyping a DB-based system that relied on both cookies and IP address/web client pairs. If the cookie was verified to work, the fallback system (IP address/web client pair) was disabled automatically. Another possibility is to explicitly store an index to the session information as a form/URL variable, in the HTML, whose value's validity expires in a reasonable timeframe. The actual information would be stored in a DB backend (cf. prior posts for examples).	[reply] [d/l]
Re: CGI.pm param not following post by hacker (Priest) on Jul 10, 2002 at 10:44 UTC
I think what you're looking for is hidden fields to pass state information from one invocation to the next. It can be as simple as: `print $query->hidden(-name=>'hidden_name', -default=>['value1','value2'...]);` [download] You could also try the various examples found in Super Search for 'hidden fields' here. merlyn has a column that illustrates a method of using hidden fields over here at Stonehenge.com also. O'Reilly has a CGI Programming with Perl book that has a chapter describing persistant data inside as well. Peachpit Press also has a chapter called 'Remembering What Your Visitors Tell You' in their book Perl and CGI for the World Wide Web.	[reply] [d/l]
Re: CGI.pm param not following post by hiseldl (Priest) on Jul 10, 2002 at 13:47 UTC
If you don't want to use cookies: you can use a hidden field to store a user session key, and then use the session key as the lookup key for your DB_File or DBI data store. This will reduce the amount of traffic that you have to send back and forth, and it allows you to pass the session key to other scripts, etc. with minimal effort. -- .dave.	[reply]