why aren't these checkboxes checked?

Discussion in 'Perl Misc' started by ioneabu@yahoo.com, Jan 7, 2005.

  1. Guest

    #!/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
    , Jan 7, 2005
    #1
    1. Advertising

  2. wrote:

    > 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--

    --
    Cocoa programming in Perl: http://camelbones.sourceforge.net
    Hire me! My resume: http://www.dot-app.org
    Sherm Pendley, Jan 7, 2005
    #2
    1. Advertising

  3. Guest

    Sherm Pendley wrote:
    > wrote:
    >
    > > 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--
    >
    > --
    > Cocoa programming in Perl: http://camelbones.sourceforge.net
    > Hire me! My resume: http://www.dot-app.org


    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
    , Jan 7, 2005
    #3
  4. Guest

    wrote:
    >
    > 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


    >
    > 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


    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , Jan 8, 2005
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. yurps
    Replies:
    1
    Views:
    6,887
    rajeshthangarasu1983
    Feb 29, 2008
  2. Replies:
    2
    Views:
    332
  3. Clint Olsen

    Why aren't signed/unsigned type clashes checked?

    Clint Olsen, Jul 10, 2003, in forum: C Programming
    Replies:
    10
    Views:
    482
    Dan Pop
    Jul 11, 2003
  4. Karlo Lozovina
    Replies:
    1
    Views:
    309
    Jonathan Ellis
    Apr 16, 2006
  5. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,849
    Smokey Grindel
    Dec 2, 2006
Loading...

Share This Page