(CGI::Vars) Re: Variable Variables

Doing something like this is bad practice, for a variety of reasons. Mostly because if someone adds a form field that you did not prepare for, it might affect a different part of the script. For example, if someone added a form field called "key" your script would die because it would try to set $key to the form value, which is also the loop iterator.

If you want to avoid calling $query->param() each and every time you want to access the form values, and I sympathize, you should try something like this:

use strict;
use CGI;

my $query = new CGI; # this will import the form values
my %vars = $query->Vars(); # this will "export" the form values

print "Name: ", $vars{name}, "\n";
[download]

...et cetera. See the CGI.pm manpage for more info about the Vars syntax.

HTH

'kaboo

Comment on (CGI::Vars) Re: Variable Variables Select or Download Code

Replies are listed 'Best First'.
Re: (CGI::Vars) Re: Variable Variables by Kanji (Parson) on Dec 05, 2000 at 09:38 UTC
There's also `import_names()`, which takes an argument of a namespace (anything but `main::` ;) to import parameters into, so that you can say `$namespace::var` instead of `param('var')` or `$cgi->param('var')`. `use CGI qw/import_names/; import_names('X'); print $X::hello;` [download] Another case of TMTOWTDI. :))) --k. (Although you could always override CGI.pm's `import_names()` if you really, really, really wanted `$hello`, but the reasons its disabled by default are sound -- see the docs for more.)	[reply] [d/l]
Re: (CGI::Vars) Re: Variable Variables by Adam (Vicar) on Dec 05, 2000 at 07:50 UTC
Actually, his code didn't have that particular flaw. He only creates the variables in his array. But your point is good, its something people need to think about. I also like the $query->Vars(); suggestion. never seen that before. cool :-)	[reply]
Re: Re: (CGI::Vars) Re: Variable Variables by mwp (Hermit) on Dec 05, 2000 at 07:55 UTC
Thanks. Vars() is relatively new, around CGI.pm 2.50 if I remember correctly. I understand what you're saying... he only creates the variables in the list he defines for the foreach loop. I guess what I was trying to imply was that whomever edits the form and adds a field is going to have to come into the CGI script and modify that too, creating the situation I described. =) You would hope the programmer in question would realize their folly and change the formfield name so that it wouldn't break the script, but never forget O'Toole's postulate: Murphy was an optimist.	[reply]
Re: (CGI::Vars) Re: Variable Variables by repson (Chaplain) on Dec 05, 2000 at 08:15 UTC
I recall seeing a link to a PHP(?) bug report because the automatic action in that language is to create variables in main namespace named after the form elements. However people could write over package globals that people didn't want changed, compromising security.	[reply]
Re: (CGI::Vars) Re: Variable Variables by Anonymous Monk on Dec 06, 2000 at 01:59 UTC
This is OK unless a parameter is specified more than once as in '?ar=3&ar=2' - in this case Vars loses a value. The following is what I use: `my %args = (); # get cgi parameters into a hash. preserve multi-valued # parms for my $p ( $cg->param() ) { my @tmp = $cg->param($p); if ( scalar @tmp == 1 ) { $args{$p} = $tmp[0] } else { $args{$p} = [ @tmp ] } }` [download] Now %args has your params, w/ multi-valued ones as references to arrays. - Bob Niederman	[reply] [d/l]
(the magical NUL) Re (2): (CGI::Vars) Re: Variable Variables by mwp (Hermit) on Dec 06, 2000 at 10:01 UTC
That's a good point. (Neat routine, too.) But consider this: Before coming here, and before CGI.pm matured, I was a notorious advocate of cgi-lib.pl. As a matter of fact, part of the reason that the Vars method in CGI.pm was added was to facilitate the transition of cgi-lib.pl users over to CGI.pm. In cgi-lib.pl you would do something like this: `require "cgi-lib.pl"; &ReadParse(*input); # store form values in the glob "input" print &PrintHeader; # print HTML header print "Name: ", $input{name}, "<br>\n";` [download] This was very nice syntax and worked well for me for many moons. =) When the form parser would encounter multiple values for a single field name, it would string them together with the NUL character (by default), so you could do this: `print "First value: ", $input{valueList}, "<br>\n"; print "All values: ", join("<br>\n", split(/\0/, $input{valueList}));` [download] And it would do exactly what you'd expect it to do. Neat, huh? Well, conveniently enough, CGI.pm inherited this behaviour. But don't take my word for it: `#!/usr/bin/perl -w # /~alakaboo/cgi-perl/multi.pl use strict; use CGI; my $q = new CGI; my %v = $q->Vars(); print $q->header('text/plain'); { local $" = "\n"; my @tmp = split /\0/, $v{ar}; print "@tmp"; }` [download] Voila.	[reply] [d/l] [select]