in reply to is there anything more VEXING than checking the $cgi->checkbox ?

OK, studying the CGI.pm sub , I see where the author seems to be evaluating "override" where in some circumstances, instead of honoring $checked, he uses $self->_checked() which seems to seek only the value "checked", inconsistent with the other comment, that it only needs to be TRUE.

So I added override => 1 and now everything is working.

  • Comment on Re: is there anything more VEXING than checking the $cgi->checkbox ?

Replies are listed 'Best First'.
Re^2: is there anything more VEXING than checking the $cgi->checkbox ?
by haj (Vicar) on Nov 20, 2023 at 15:33 UTC

    This is explained in the documentation: Per default, CGI::HTML::Functions is state-preserving, that is, input from a previous requests overrides the defaults in the code. The simple example given by pryrt works because there is no previous request.

    You can use the -nosticky pragma to prevent that generally, or use override on a per-element basis, if you want a different behavior.

Re^2: is there anything more VEXING than checking the $cgi->checkbox ?
by pryrt (Abbot) on Nov 20, 2023 at 15:49 UTC
    So I added override => 1 and now everything is working.

    Ah, that makes sense. If you had previously submitted the form with that specific checkbox being unchecked, then the normal behavior of CGI.pm is to keep that existing state when it prints the new copy of the HTML -- that would explain why the results with no input using my code didn't match what you were seeing.

    To make sure that your form is always in the "pristine" state rather than inheriting from the input parameters it received, then you have to tell CGI.pm to do it that way.

    The CGI.pm documentation for 4.51 explains this in the CGI::HTML::Functions "CREATING FILL-OUT FORMS:" section (as does 4.60 in the equivalent section of the docs):

    Another note The default values that you specify for the forms are only used the first time the script is invoked (when there is no query string). On subsequent invocations of the script (when there is a query string), the former values are used even if they are blank.

    It then goes on to explain that you can either use the param() method to set the value for that parameter to what you want, or you can use the override flag to have the "default" values you supply in your code used even if there was an input value from the query string or post parameters.

Re^2: is there anything more VEXING than checking the $cgi->checkbox ?
by cavac (Prior) on Nov 20, 2023 at 15:30 UTC

    which seems to seek only the value "checked"

    "checked" is the value that HTML uses. Well, sort of, most of the time. The original specs of HTML are rather vague, and the modern ones backwards compatible. And there is the thing with XHTML, which needs to be valid XML as well as valid HTML.

    So a pre-checked checkbox can be specified like this in HTML

    <input type="checkbox" checked> <input type="checkbox" checked="checked"> <input type="checkbox" checked="">

    But in the stricter XHTML spec, only this one seems to be valid:

    <input type="checkbox" checked="checked">

    I dimly remember that the return value in a form for a checkbox is also a bit strange, i think it's "on" or something similar. Don't quote me on that, i never use those damn things in my web framework directly anymore sine i wrote a touch-friendly replacement (that also accepts custom values for the "on" and "off" states) about 15 years ago...

    PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP