why aren't these checkboxes checked?

I

ioneabu

#!/usr/bin/perl

use warnings;
use strict;
use CGI (':standard');

my $items = param('items');
my @defaults = split ' ', $items;
chomp @defaults;
print header(),start_html();
print start_form();
print table({-border=>1},Tr(td(\@defaults)));
print br(), textfield(-name=>'items');
print br(), checkbox_group(-name=>'boxes',
-values=>\@defaults,
-defaults=>\@defaults);
print br(), submit();
print end_form();

This is a CGI program in which you can type a word or a list of words
separated by a space in the textfield and a checkbox group is generated
from those words. They should all be checked because of the default
setting. Why are they not being checked by default?

Thanks!

wana
 
S

Sherm Pendley

print br(), checkbox_group(-name=>'boxes',
-values=>\@defaults,
-defaults=>\@defaults);

This is a CGI program in which you can type a word or a list of words
separated by a space in the textfield and a checkbox group is generated
from those words. They should all be checked because of the default
setting. Why are they not being checked by default?

Not certain *why* it happens exactly, but it appears to depend on the
name you give the group. If I use 'boxes', it (mis)behaves as you've
described. If I name it 'my_boxes' or 'BOXES', it works as it should.

sherm--
 
I

ioneabu

Sherm said:
Not certain *why* it happens exactly, but it appears to depend on the
name you give the group. If I use 'boxes', it (mis)behaves as you've
described. If I name it 'my_boxes' or 'BOXES', it works as it should.

sherm--

I found a possible solution but not sure why I need to do it.

print br(), checkbox_group(-name=>'boxes',
-values=>\@defaults,
-defaults=>\@defaults,
-override=>1);

I don't know why I have to override in this situation, but there is
mention of it in the CGI.pm text which is not on the CGI.pm home page.
That discussion is more about using a checkbox_group where you have
another item with the same name.

It's like the philosophy that turning a machine off and on is the first
thing to try in fixing a problem. Always try -override=>1 if your
widget doesn't behave as expected.
In this case, I don't understand the logic behind it.

Thanks!

wana
 
X

xhoster

I found a possible solution but not sure why I need to do it.

print br(), checkbox_group(-name=>'boxes',
-values=>\@defaults,
-defaults=>\@defaults,
-override=>1);

I don't know why I have to override in this situation, but there is
mention of it in the CGI.pm text which is not on the CGI.pm home page.
That discussion is more about using a checkbox_group where you have
another item with the same name.

Once I read this then it was obvious what was going on.

The very first time the script is invoked (with no parameters), the script
does exactly what you want, it prints all the checkboxes as being checked.
But since there are zero checkboxes at this point, you don't get to see
this fact (unless you look at the hidden .cgifields parameter).

Once you fill out that form and submit (causing the second invocation of
your script), CGI does just what it promises when you don't specify
"override" or "nosticky". It ignores the default values you specify in
your code, and instead uses values that were just submitted. The values
that were just submitted for the form element named "boxes" are, of course,
the empty list. So that is what it uses.

If you simply do:

print br(), checkbox_group(-name=>'boxes',
-values=>\@defaults,
-defaults=>\@defaults) if @defaults;

Then it will also work the way you wanted (or maybe not, I'm not exactly
sure what you wanted!)

Perhaps the sticky CGI should us some extra hidden fields so that in the
case of checkbox groups, it remember not only which ones were checked, but
also which ones were offered but not checked. That way it could use our
coded defaults for new members of the group, while being "sticky" only with
respect the old members.

But anyway, when parts of a form depend on what was submitted from the
previous form, it is bad practise to ignore the fact that at least once,
there was no previous form submittion.

Xho
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top