Yes, the map is broken, but only because there is no taking into account multiple values for a name. If that is fixed, I prefer it to Vars() for two reasons. First, you can use a proper data structure instead of having to split on NULs. Second, why introduce NULs when we know that they can be used to create security holes? One way to fix the map is this:

my %param = map { $_ => [$cgi->param($_)] } $cgi->param();
[download]

That works, but then all values are array refs and many object. A cleaner method allows most values to simply be values and only create array refs when you have multiple values:

#!/usr/bin/perl -wT
use strict;
use CGI qw/:standard/;

my %params = map { $_ => get_data( $_ ) } param;

sub get_data
{
    my $name   = shift;
    my @values = param( $name );
    return @values > 1
        ? \@values
        : $values[0];
}
[download]

Of course, some might argue about inconsistent mixing of array refs and regular scalars, but I still think it's cleaner.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Of course, some might argue about inconsistent mixing of array refs and regular scalars, but I still think it's cleaner.

I'll bite. If you (obviously not Ovid, who knows better) don't know whether your form field can generate multiple values, you don't understand the problem space. There be dragons.

Besides that, what if someone malicious or curious decides to edit the HTML locally or to submit extra information? If you don't check *every* variable to see if it's an array reference, the best you can hope for is a harmless crash. Try that with CGI, which for all its warts, handles this nicely.

Yeah, the map solution with array references is a sight better than the old cgi-lib.pl approach, but it's merely false laziness. You have to know what data to expect.