Thanks, Boris! I had not heard of sessions before, so I did a little(okay, a lot of) reading on it. I like CGI::Session (meaning I actually understood how to use it). It also gives a nice overview of the various methods used to keep data along for the "ride" as a user moves around, and the pros and cons of each method.

We don't have CGI::Session loaded on our Unix server, but I can (and will) load it on my Windows ActiveState variety so I can play with it. Then, I will make some fudge, carry it to the dba, bat my eyelashes, and beg him to load CGI::Session on the Unix box. ;-)

Lori

You have several choices.

1. If I recall correctly CGI has a 'sticky mode' so it can allow you to populate a second form based on the response to the first form. This is suitable for very simple situations.
2. You can't pass just @names to HTML::Template - you have to pass it a reference to the entire HASH, in fact you can even pass it the object and it will use the param method to extract the HASH!
3. A session system is good too, as you say TIMTOWTDI. If you need the capability of a session managed application, CGI::Session makes it very easy. Fortuantely most of the time my apps are session managed so the I can tuck things in a session and get them back as has already been described to you.
4. Data::FormaValidator and its close cousin HTML::FillInForm can be used to implement the same sort of thing with very flexible validation along the way.
5. POST method is safer than GET, in only a very minor way. But the sue of a sessioning system will allow the variables never to leave your server, so you don't have so much to worry about. It also means you can store other incidental information along the way as well and you can expire not only the entire session, but a part of the session.
   For example, my users have to log-in, but after 30 minutes of no usage they are automatically logged-out. By using the expire method of CGI::Session you can have a session which persists (as mine do) but the user needs to log back in again after a period of inactivity.
6. Our very good frinds, in teh form of Lincoln Stein and otehrs have been so gracious and generous as to bless us with CGI.pm and its related modules. Please do not make the mistake of trying to do it yourself.

jdtoronto

First, thanks for your responses and explanations. I admit I burst into laughter when I read #6... the idea that I might roll my own when I can barely read and understand any POD... <giggle> I just wish it were even possible to roll my own at this stage! ;-)

I've been trying to play with CGI::Session, but I can't get it to work for me. I don't know if it's because I'm trying to save ALL my CGI form variables PLUS my TMPL_VAR variables... Is that even possible?

As for CGI.pm, wouldn't CGI.pm's "stickyness" be the default behavior? I see where there's a pragma called "-nosticky". I can't seem to pass the variables to the second script, even though I successfully passed them to the first script (and I suspect it's because the variables were in a form and CGI.pm likes that). So, am I correct in my understanding that CGI.pm won't pass the form variables a second time because there's no form?

edited: left the following question out...

Now, on to item #2... that's intriguing. I'd like to make sure I understand what you're saying. I can save all my template variables in an array, then pass that array over to the template and somehow (don't know how yet) I can then "extract" them into individual items I can use? Did I get that right?

Thanks!

Lori

I just wish it were even possible to roll my own at this stage! ;-)

I was jokingly referring to the 'googling' you did when you came up with all sorts of references to getting the $ENV variable and parsing it! Just don't do it please :)

As for CGI.pm, wouldn't CGI.pm's "stickyness" be the default behavior? I see where there's a pragma called "-nosticky". I can't seem to pass the variables to the second script, even though I successfully passed them to the first script (and I suspect it's because the variables were in a form and CGI.pm likes that). So, am I correct in my understanding that CGI.pm won't pass the form variables a second time because there's no form?

I am going to pass on comeenting here. Yes, as I recall, CGI.pm's default is sticky, but it is a LONG time since I used it that way.

I've been trying to play with CGI::Session, but I can't get it to work for me. I don't know if it's because I'm trying to save ALL my CGI form variables PLUS my TMPL_VAR variables... Is that even possible?

Sheesh! Why does everybody have trouble getting CGI::Session to work! It's easy. OK, here we go:
1. Create you database table, make sure that you have the required two fields. e.g.

   SET FOREIGN_KEY_CHECKS=0;
   #----------------------------
   # Table structure for sessions
   #----------------------------
   CREATE TABLE `sessions` (
     `id` varchar(32) NOT NULL default '',
     `a_session` text NOT NULL,
     UNIQUE KEY `id` (`id`)
   ) TYPE=MyISAM;
   [download]

   and make sure that the 'a_session' is at least a BLOB size field.
2. Set up the database and get a DBH object back.

   my $config = {    DSN            => 'DBI:mysql:session',
                   MySQLunm    => 'ipsofalco',
                   MySQLpwd    => 'ipsoquango',
   };
   
   my $dbh = &createDBconnection( $config->{DSN}, $config->{MySQLunm}, $c
   +onfig->{MySQLpwd} );
   # Get a CGI object, it will be filled if a form was
   #submitted and will have a cookie in teh header
   #if one had been set.
   my $q = new CGI;
   #Initialize the session, if their is a cookie in the
   #CGI object then the CGISESSID will be the value of an
   #existing session, otherwise it creates a new session
   my $session = new CGI::Session("driver:MySQL", $q, {Handle=>$dbh});
   
   #$rdcookie is the value of the cookie that was already
   # in the header read=past tense in this case.
   my $rdcookie = $q->cookie("CGISESSID");
   #$id is the session id (an MD5 hash) of the session.
   my $id = $session->id();
   
   # Set cookie with new expire time
   my $cookie = $q->cookie(-name=>'CGISESSID', -value=>$session->id, -exp
   +ires=>'+1d');
   [download]

3. Now we can write to the session, read from it, clear it and expire things, like this in a crude shopping cart:

   sub addItemCart {
       my ($cgi, $session, $orderitem) = @_;
   
       my $orderitem = &getItemForCart($cgi, $session);
   
       # get current cart contents
       my $cart = $session->param("CART") || [];
       # add selected item
       push @{$cart}, $orderitem;
       # update the CART in the session
       $session->param( "CART", $cart );
       $session->flush();
       return displayCart($cgi, $session);
   }
   [download]

   Does nothing more than get a hash of an item and adds it to the CART value(a list of hashes) which is saved in the session parameters.
4. To clear the cart we clear the session value that was saved:

   sub clrCart {
       my ($cgi, $session) = @_;
   
       $session->clear(["CART"]);
       $session->flush();
       return &displayCart($cgi, $session);
   }
   [download]

   and in this case display the updated cart.
Save what you like int he session parameters. Save an entire HASH, darn it, save an array of hashes just like my silly little cart.

To see some more code - much more complete, have a look at jdtoronto's scratchpad The full working version is posted there.

jdtoronto

I missed part of your questions:

I can save all my template variables in an array, then pass that array over to the template and somehow (don't know how yet) I can then "extract" them into individual items I can use? Did I get that right?

Not quite, you can pass it a hash reference, if you want to fill in several TMPL_VAR's you can do this:

$template->param( 'username' => 'john',
                  'userstatus' => 'paid' );
[download]

So you can build a HASH and pass in a reference. Oh. lets not forget, in CGI the Vars method will return either a HASH of a HASHREF of all the parameters, instead of iterating over them using the param method you can get then in one bite. If you use

$hashref = $q->Vars;
[download]

then you get a tied HASHREF which you can pass to H::T.

$template->param( $hashref );
[download]

will set all the variables for which a hash key exists. In this case <TMPL_VAR name="username"> and <TMPL_VAR name="userstatus">.

Interestingly, H::T can also accept an object with a param method, similar to CGI. Well, this then means that you should be able to pass the query object to H::T, I havn't tried it, but it should work.

$template->param( associate => $q );
[download]

HTML::Template is immensely flexible and can be used in many ways, and it can be fed in many and various ways too!

jdtoronto