Re: [WWdevel] CGI weirdness under Apache 1

[Michael G. <ga...@ma...>]

On Jul 20, 2006, at 3:20 PM, Sam Hathaway wrote:

> So you'd think that the solution would be to simply add the "-
> nosticky" pragma, like we originally tried. However, from looking at
> the CGI.pm code, I think -nosticky doesn't do what we think it does.
> What it appears to do is suppress the output of hidden ".cgifields"
> fields naming each of the radio buttons, checkboxes, and scrolling
> lists in the form. (And also give the default name ".submit" to
> unnamed submit buttons.) THAT'S ALL.
>
>   As far as i can tell, all that ".cgifields" does is ensures that
> the parameter *names* for checkboxes, radio buttons, and scrolling
> lists are still known to CGI.pm even if none of them are selected
> (and thus don't appear in the request). This has very little to do
> with form field "stickiness", despite statements to the contrary in
> the docs. (The only connection is that it prevents checkboxes, radio
> buttons, and scrolling lists from being reset to their defaults if
> none of their items are selected.) It looks to me like the only way
> to turn off form field stickiness is to specify "-override=>1" in
> each field.
>
> This seems really weird to me, since it implies that the CGI module
> documentation is just plain wrong. Could you do me a favor and look
> at $NOSTICKY in the CGI.pm source and tell me if I'm missing  
> something?

I've looked through the code.  As best I can tell you are right.   
We'll need -overrides
in nearly all of the CGI::() calls since we assumed that our values  
wouldn't be overridden
by values from the param list.  I remember that when we did the CGI  
scripts for WeBWorK 1.x
we had a lot of problems of when to use overrides and when they  
weren't needed.  We were
probably using GET a good deal more often in that case and actually  
needed the overrides.

Adding overrides seemed to work.  I added several in my first attempt  
to analyze the problem.
I got tired after awhile, but it is not that overwhelming a chore --  
just tedious. I think we can
safely assume that we want -override =>1 in every CGI call with a - 
name parameter.

I haven't been doing
lots of testing with the standard CGI -- are you still getting weird  
behavior a lot of the time?

We could also decide to go with CGIeasytags.  If the extra {} are  
bothering you, we can
be a bit more clever about deciding whether the input to CGI::foo()  
is of the form:
(1) CGI::foo({params], text]    -- easy
(2) CGI::foo(-name=>'foo', value = >'bar') or
(3) CGI:: foo( "name", "foo", "value", "bar")  i.e.  is supposed to  
produce namefoovaluebar
(4)CGI::foo("foo", "bar");

Nothing would be perfect but one could do a lot more than I tried to.

Take care,

Mike


> -sam
>