Re: br tag in CGI.pm V2.91
by jasonk (Parson) on Apr 09, 2003 at 21:11 UTC
|
I don't think you are missing something, it looks like it really is a bug (or at least an oversight). The code that generates this html looks like this (this is the end of a sub generated by _make_tag_func which is called by AUTOLOAD in CGI.pm):
return $XHTML?"\L<br\E$attr />":"\L<br\E$attr>" unless @_;
my($tag,$untag) = ("\L<br\E$attr>","\L</br>\E");
my @result = map { "$tag$_$untag" }
(ref($rest[0]) eq 'ARRAY') ? @{$rest[0]} : "@rest";
return "@result";
It seems that the intention of this is generate a container-style tag if given arguments, and a standalone tag without arguments. The oversight is that if you call it as an object method it doesn't deal with the fact that the object is at $_[0]. So you end up with this effect:
#!/usr/bin/perl -w
##################
use CGI qw/:standard/;
print "foo".br()."\n";
my $q = new CGI;
print "foo".$q->br()."\n";
__END__
foo<br />
Use of uninitialized value in join or string at (eval 2) line 15.
foo<br></br>
That uninitialized value warning comes from the generated sub above. I think the moral is that nobody ever expected the html generating functions to be called as object methods, and it should work fine if you import them with :html and call them as regular subs.
| We're not surrounded, we're in a target-rich environment! |
|---|
| [reply] [d/l] [select] |
Re: br tag in CGI.pm V2.91
by BrowserUk (Patriarch) on Apr 09, 2003 at 21:06 UTC
|
Strange. I have CGI.pm v2.752, and by default, it produces XHTML complient <BR /> tags, and states in the pod that this is so unless the -no_xhtml option is used?
-no_xhtml
By default, CGI.pm versions 2.69 and higher emit XHTML (http://www.w3.
+org/TR/xhtml1/).
A quick test shows this to be the case C:\test>perl -mCGI -le"$q=new CGI; print $CGI::VERSION; print $q->br;"
2.752
<br />
C:\test>
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] [d/l] [select] |
|
|
#!/usr/bin/perl
use strict;
use CGI;
my $q = CGI->new();
print "$CGI::VERSION\n";
print $q->br."\n";
# and it output this:
2.91
<br></br>
Very weird.
cLive ;-) | [reply] [d/l] |
|
|
C:\test>perl -mCGI -le"$q=new CGI; print $CGI::VERSION; $CGI::XHTML=1;
+ print $q->br;"
2.91
<br></br>
I even tried explicitly setting $CGI::XHTML = 1; directly--even though it appears to be set to this at line 45 of CGI.pm, and the only place where I can see that it gets modified is at line 718 as a result of the -no_xhtml option. The code generating the BR markup
1948 $break = $XHTML ? "<br />" : "<br>";
2116 $break = $XHTML ? "<br />" : "<br>";
looks like it ought to do the right thing.
Upshot: I guess it's time to send Lincoln Stein a bug report. You could try for a patch as well, but I'm scuppered if I can see where to patch:)
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] [d/l] [select] |
|
|
|
|
|
|
|
for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc'
.'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$
p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}
| [reply] [d/l] [select] |
Re: br tag in CGI.pm V2.91
by jonadab (Parson) on Apr 10, 2003 at 17:18 UTC
|
In XML (including XHTML), the following are all equivalent:
<foo></foo>
<foo />
<foo/>
I think this is true for all tags except the XML
declaration and the DOCTYPE, which are special.
There may be other special tags, but if so I am
not aware of them. They would have to start with
a non-alphanumeric character (e.g., a ! like the
doctype or a ? like the XML declaration) in order
to prevent their being parsed as regular XML tags.
The third form is the most minimalist, but it creates
problems for certain legacy browsers, so one of the
first two approaches is recommended. Which one depends
on whom you ask. They are equivalent if the program
parsing them is compliant.
for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc'
.'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$
p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}
| [reply] [d/l] [select] |
|
|
If it's a legacy browser, it shouldn't have X/HTML delivered to it - I suspect what cLive ;-) is doing is delivering X/HTML as HTML, which would cause Mozilla to go into tagsoup mode (i.e., you're not in strict or even transitional, you're in nothing).
I tested my Moz, and <br/> is equivilent to <br></br> in an X/HTML document delivered as such. For HTML documents, <br> is the only valid markup - <br/> won't work, and <br /> is invalid HTML (although they do suggest it in the XHTML spec as some kind of backward compatible thing, which is wrong IMO).
Such is life :( I tend to deliver valid X/HTML to those clients that can handle it, and tagsoup to the rest.
| [reply] |
Re: br tag in CGI.pm V2.91
by PodMaster (Abbot) on Apr 10, 2003 at 01:12 UTC
|
perl -MCGI=br -e die(br)
<br /> at -e line 1.
I am personally beginning to hate CGI.pm, cause with every new version more bugs crop up. I've cut back on using the html generation shortcuts except for one-off scripts, and I am beginning to completely phase out all usage of CGI.pm.
MJD says you
can't just make shit up and expect the computer to know what you mean, retardo!
I run a Win32 PPM
repository for perl 5.6x+5.8x. I take requests.
** The Third rule of perl club is a statement of fact: pod is sexy.
|
| [reply] [d/l] |
|
|
Out of curiosity, what are you using in place of it? There are decent alternatives out there and I'm curious to know which you chose and why.
Cheers,
Ovid
New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)
| [reply] |
|
|
Well, Apache::Request wherever available (obvious reasons),
and CGI::Simple (despite a few minor annoyances relating to VERSION).
CGI::Simple well tested and lightweight, and will soon be improving (i hope) to handle mod_perl without work on the programmers part (delete __DATA__/use SelfLoader; is not cool)
The only other decent alternative "might" be CGI-Minimal, but I won't even consider it due to the sorry state of affairs that the test suite is (when that situation improves, i'll give it a closer look).
And before you say CGI-Thin, that thing's got too many bugs pending.
I really do feel we need a pure-perl CGI module akin to Apache::Request that is well written.
How about you?
MJD says you
can't just make shit up and expect the computer to know what you mean, retardo!
I run a Win32 PPM
repository for perl 5.6x+5.8x. I take requests.
** The Third rule of perl club is a statement of fact: pod is sexy.
|
| [reply] |
|
|
| A reply falls below the community's threshold of quality. You may see it by logging in. |