Any time you're tempted to create a variable with a variable name, use a hash. It will save your hair, sanity, and marriage, even if you're not married. I promise.

The alternative is so Cthonically dangerous, I dare not even speak its name. Suffice it to say that when you know how to deal with the Perl equivalent of an octopus riding a unicycle, you will know when to use it.

Here's why you shouldn't do this: Part 1, Part 2, and Part 3.

And here's what you should do: use a hash or something similar. You have the right idea using $query->param, then grabbing the variables that you need to match based on a pattern. Instead of creating *variables* with those matched names, add entries to a hash.

Here's the deal: When you're writing a CGI, you know (well, most of the time) all the form element names. Lots of times there's lots of elements, and for security's sake you only want to mess around with the elements that you care about. (i.e., if some bozo submits a form element named "foo" you want to ignore it and not import it accidentally into your namespace.) So, here's a favorite idiom I like to use:

@vars = qw(name rank serial_num shoe_size);
foreach (@vars) {
   ${$_} = param ($_};
}
[download]

Now, according to the (excellent) articles I should not use soft references but instead do something like this:

@vars = qw(name rank serial_num shoe_size);
foreach (@vars) {
   $form_input{$_} = param ($_};
}
[download]

Don't mean to be crazy here, but remember, variables don't kill people... people kill people.

Gary Blackburn
Trained Killer

Here's one of the summaries from the last of mjd's articles:

    One of the biggest problems in all of compter
    programming is namespace management and data
    hiding. When you use a symbolic reference you are
    throwing away forty years of expensive lessons from
    the School of Hard Knocks.
[download]

The fact is, a hash in my opinion buys you much larger than a "fractional" benefit w/r/t blowing away your variables. Why do you want to mix up your form values with variables in your application? What are you *gaining* by doing that?

You give the example of a variable called $name:

    Because it's a CGI, it is very unlikely that I'll want
    to use a "$name" variable somewhere else for
    some purpose other than sucking in the "name"
    element as in my example.
[download]

Sorry, but $name isn't a very good example of an uncommon variable name. :) That's the sort of thing that could very easily get you in trouble if your programs start getting larger, or if you start doing development in a team environment, etc.

The basic point here is: you're buying yourself nothing, save typing a couple of characters, by not using a hash. Even if you view using a hash as providing only "fractionally" more security, why not use it?

All good points, but remember that it's a CGI, which means I am (by definition) stuck with that pesky HTML form and those form elements. I want to confuse my element names with my application variables... one way of looking at it is a deliberate, controlled extension of my application's namespace to include the HTML form.

I'm not saying that using a hash is a bad idea, but I do think that we should be very careful in our choice of dogma. Perl, far more than most languages, is not a black and white affair. I challenge the dogma that "all soft references are bad" by presenting a reasonable situation where some programmer somewhere might choose to use them to advantage.

Gary Blackburn
Trained Killer

You seem to be a good enough programmer that you can probably get away with symbolic references in this case. (I tend to use the list of allowed variables too.)

I don't like the idea of encouraging beginning programmers to use them, however. It's a quick way to open up a security hole in a CGI script, and you don't get the protection of -w and strict. Worst yet, it lets beginning programmers tie themselves up in knots trying to make "var₁", "var₂", ... "var_n" when they should be using an array or a hash.

Programming well is hard enough without encouraging people to put on blindfolds, put raw meat down their pants, and dangle over an alligator pit. People like you and I, who know what we're doing (or can fake it convincingly) can get away with that sort of thing... but I'm not going to recommend it for someone who can't tell me what a typeglob is, for example.

ALL HAIL BRAK!!!

For me, I think in the following way: if a question has only one answer, with few choices, a Radio Button is best. If you only want one item, but the list of choices may grow over time, a pull-down may be best. If you want a bit of info that is in no way dependent on other info, checkboxes are the answer.

Some things make themselves more obvious. Things like multiple choice questions, with potentially long answers, do the answers in HTML text and put radio buttons next to them. Long questions with short answers, pull-down menues. I don't think I've ever needed to use a multiple select in anything I have created. That data could always be represented in other methods.

As far as "prettying up" the form elements, in my current project, I assign some variables as "selected" or "checked" and then include them in the HTML form element. That way I can maintain state between calls.