CGI.pm annoying xHTML output

[FrankB]

Hello,

when creating a form with CGI.pm, no matter if it is
use CGI;
$q = new CGI qw /:all -debug/;
print header and start the html etc..

print $q->start_form; OR
print $q->start_multipart_form();
print $q->textfield('blah');
print $q->end_form;
#etc..

it *always* returns an obsolete trailing HTML "<div></div>" container
before the closing tag of the form.

Any ideas ? It seems not to be
a known issue.

(Perl 5.8.1 on linux)

 

[Glenn Jackman]

Hello,

when creating a form with CGI.pm, no matter if it is
use CGI;
$q = new CGI qw /:all -debug/;

Those lines should read:
use CGI qw/:all -debug/;
my $q = new CGI;

print $q->end_form;

it *always* returns an obsolete trailing HTML "<div></div>" container
before the closing tag of the form.

A browse through the CGI.pm indicates it outputs that div container if
sticky is on, so do this:
use CGI qw/:all -debug -nostick/;
or call:
CGI::nosticky(1);
before ending the form.

 

[Glenn Jackman]

Hello,

when creating a form with CGI.pm, no matter if it is
use CGI;
$q = new CGI qw /:all -debug/;

Those lines should read:
use CGI qw/:all -debug/;
my $q = new CGI;

print $q->end_form;

it *always* returns an obsolete trailing HTML "<div></div>" container
before the closing tag of the form.

A browse through CGI.pm indicates it outputs that div container if
sticky is on, so do this:
use CGI qw/:all -debug -nosticky/;
or call:
CGI::nosticky(1);
before ending the form.

 

[FrankB]

Glenn Jackman formulated the question :

Those lines should read:
use CGI qw/:all -debug/;
my $q = new CGI;

Ok.
Is the lexical variable really mandatory ?

A browse through the CGI.pm indicates it outputs that div container if
sticky is on, so do this:
use CGI qw/:all -debug -nostick/;
or call:
CGI::nosticky(1);
before ending the form.

Thanks, and I indeed didn't think about checking the module itself..
(smashes forehead)

 

[Todd]

Hello,

when creating a form with CGI.pm, no matter if it is
use CGI;
$q = new CGI qw /:all -debug/;
print header and start the html etc..

print $q->start_form; OR
print $q->start_multipart_form();
print $q->textfield('blah');
print $q->end_form;
#etc..

it *always* returns an obsolete trailing HTML "<div></div>" container
before the closing tag of the form.

Any ideas ? It seems not to be
a known issue.

(Perl 5.8.1 on linux)

Are you using the latest version of CGI? That problem went away when I
installed 3.15.

Todd

 

[Glenn Jackman]

Glenn Jackman formulated the question :

Ok.
Is the lexical variable really mandatory ?

If you're using 'use strict' (as you should be) it's a good idea.

 

[John Bokma]

Glenn Jackman formulated the question :

Ok.
Is the lexical variable really mandatory ?

If you have put use strict; and use warnings; before use CGI ..., yes.

Also, I recommend to call the variable $cgi instead of $q (or $query).

Thanks, and I indeed didn't think about checking the module itself..
(smashes forehead)

Stuff like this *should* be documented IMO.

One final remark: request.net is probably not your domain (if it is, skip
this). Don't abuse a domain you don't own. Use invalid as tld.

 

[Todd]

Are you using the latest version of CGI? That problem went away when I
installed 3.15.

Todd

It was fixed in 3.12 (#8):

Todd

http://search.cpan.org/src/LDS/CGI.pm-3.17/Changes

Version 3.12
1. Fixed virtual_port so that it works properly with https protocol.
2. Fixed documentation for upload_hook().
3. Added POSTDATA documentation.
4. Made upload_hook() work in function-oriented mode.
5. Fixed POST_MAX behavior so that it doesn't cause client to hang.
6. Disabled automatic tab indexes and added new -tabindex pragma to
turn automatic indexes back on.
7. The url() and self_url() methods now work better in the context
of Apache
mod_rewrite. Be advised that path_info() may give you confusing
results
when mod_rewrite is active because Apache calculates the path
info *after*
rewriting. This is mostly worked around in url() and self_url(),
but you
may notice some anomalies.
8. Removed empty (and non-validating) <div> from code emitted by
end_form().
9. Fixed CGI::Carp to work correctly with Mod_perl 1.29 in an
Apache 2 environment.
10. Setting $CGI::TMPDIRECTORY should now be effective.

 

[A. Sinan Unur]

Hello,

Don't multi-post.

http://lipas.uwasa.fi/~ts/http/crospost.html

Sinan
--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html

 

[FrankB]

Glenn Jackman brought next idea :

If you're using 'use strict' (as you should be) it's a good idea.

Thanks again.

 

[FrankB]

John Bokma brought next idea :

If you have put use strict;

Which was not the case

and use warnings; before use CGI ..., yes.

Which is the case.

Also, I recommend to call the variable $cgi instead of $q (or $query).

And that's another tip.

Thanks.

 

[John Bokma]

John Bokma brought next idea :
[..]

If you have put use strict;

Which was not the case

But it's a good thing to do it. Ages ago, different language, I typed
width as widht once, which was quite hard to track down, since it got
initialized with zero, which sometimes was the same value as width, and
sometimes not.

Which is the case.

And that's another tip.

Thanks.

You're welcome

 

[Anno Siegel]

Glenn Jackman formulated the question :

Ok.

The second line should really read

my $q = CGI->new;

Avoid indirect object notation where possible, especially when there are
no arguments to the call.

Anno

 

[Glenn Jackman]

The second line should really read

my $q = CGI->new;

Avoid indirect object notation where possible, especially when there are
no arguments to the call.

I was going to quibble over your use of "should", but then I read
"perldoc perlobj". Now, I agree.

 

[Anno Siegel]

I was going to quibble over your use of "should", but then I read
"perldoc perlobj". Now, I agree.

The trouble is that indirect object notation does look nice, especially
with a constructor named "new".

my $pet = new Pet name => 'rover', kind => 'dog';

Also, Perl almost always gets it right. I guess that's why it doesn't seem
to die out like other deprecated constructs. But there *is* guesswork
involved in the interpretation. Like all constructs that rely on the
DWIMmer it should be avoided in production code.

Anno

 

[Uri Guttman]

GJ> I was going to quibble over your use of "should", but then I read
GJ> "perldoc perlobj". Now, I agree.

it has been known and documented for a long time that they are
vulnerable and that direct calls are better. it is amazing how many
cpan modules still use indirect object calls in their code and pod. and
that includes modules written by some very good perl hackers. many
newbies copy the indirect style from example code and never end up
reading perldoc perlobj. i also like the look of direct calls over
indirect.

uri