in reply to form processing

Yay! After two nights of chatterbox discussion, a few lengthy posts, and installing cgi-lib.pl on my machine (*shudder*), I've figured out why your code isn't working as you intended. :)

It turns out that cgi-lib.pl handles multi-value params (as in ?sites=1&sites=2&sites=3) by joining the values with a null character, aka "\0" and "\c@". The value you're getting from $in{sites} is actually "1 \c@2 \c@3 ". (The spaces are from your form, and the null characters are from cgi-lib.pl.) When you split on whitespace, the first value is okay, but the other values have a hidden null character.

The solution (assuming that you want to continue using cgi-lib.pl, rather than switching to the CGI module), is to change VALUE="$modSiteNumber " to VALUE="$modSiteNumber" in your form generator, and create the array with @sites = split /\0/, $in{sites}; in your form parser.

Replies are listed 'Best First'.
Re: Re: form processing
by chromatic (Archbishop) on Dec 21, 2000 at 10:33 UTC
    That's precisely why people ought to be using CGI.pm instead of cgi-lib.pl.

    How much debugging time was spent on this issue? My instinct is that the time that it would take to port this over to CGI.pm is small, in comparison.

    What might happen in the future when someone else has to maintain this code? The alternative is a simple: my @sites = $query->param('sites');