Question for the regulars

[John Bokma]

John Bokma:

Drinking water promotes drowning?

Talking about the dangers of drowning all the time to people who can't
swim, and that they should stay away from water at all times, and making
up weird stories (like water is for fishes, it's more natural to walk on
the land, or that the "Bullebak"[1] lives in the water), keeps them from
taking swimming lessons. Instead of being able to save their own live
one day, they might drown.

Yes, it can be part of a defensive
programming style too,

It is defensive programming, nothing else.

and some kinds of defensive programming (in the
limited sense as I guess you define it) do real damage

Everytime I see people talk about defensive programming I see weird
constructs that somehow must protect them from RTFM.

I already explained why I still promote <constant> == <variable>, and
that doesn't have anything to do with compiler warnings or alike, so
reset and try again.

So, uhm, you found eventually a nice story, and think now it's a smart
idea.

[1] Based on a true story, my neighbour did this. Bullebak is Bully I
guess, but of course in the minds of her kids it was a huge fish with
big teeth etc.

 

[Gunnar Hjalmarsson]

So, if CGI.pm isn't a good idea,

CGI.pm may well be a good idea, but a problem with it is that many think
it does too much, and hence is inefficient.

what would you suggest is a better alternative?

An alternative for doing what? As regards decoding CGI requests, check
out the FAQ for a start:

http://faq.perl.org/perlfaq9.html#How_do_I_decode_a_CG

Unlike before, that FAQ entry is now written in a sensible way, and it
mentions other modules.

Not using any module should you consider an option only if you know
quite a bit about the related HTML and the HTTP protocol.

I personally like the look of Templates, i.e.
Template-Toolkit.

A templating system is indeed an alternative to CGI.pm's HTML generating
part.

 

[John Bokma]

So, if CGI.pm isn't a good idea, what would you suggest is a better
alternative? I personally like the look of Templates, i.e.
Template-Toolkit. Do you have any views on this that you could
enlighten me with?

Just a word of waring: Purl Gurl is by quite some regulars in this group
(and probably elsewhere) seen as a troll. I doubt the latter, but she has
quite a different mind set compared to "the regulars" here.

At some occasions she does have a point, but often it gets lost in the
stuff she put around that very point.

And at many other times she doesn't have a point.

Anyway, my 5 cts: CGI.pm is probably not a good example of how a module
should be written, there are quite a lot of those modules at CPAN though.

I think every library written by several (maybe even written by one) person
suffers from this. Moreover, there is no plan for CPAN, so there is a lot
of wheel reinvention (at least I do see similar modules). Also, some
authors have a set of modules, and suffer from the not invented here
syndrome, ie. they prefer to use their own modules over ones already
available, and hence when you install module A, you get B,C,D, and E for
free. And in case B,C,D, and E are similar to modules you already have, you
probably won't use them.

 

[John Bokma]

HTML rendering functions, especially when I am looking to write in
more strict (X)HTML for instance. Each to his own, I guess.

Why would you use XHTML? Most people who use it don't offer it to clients
("browsers") in the correct way.

 

[A. Sinan Unur]

Yes, and it is very pro CGI.pm,

It also suggests an alternative. Read all of the entry.

....

It's quite interesting to see such opposite views by two (or more)
programmers who are obviously both talented.

Talent, it seems, is in the eye of the beholder.

Well, reading the CGI perldoc I personally think that my favourite way
to implement a CGI website would be using CGI.pm for processing needs
such as forms, but a template system such as TT, not CGI.pm's built in
HTML rendering functions, especially when I am looking to write in
more strict (X)HTML for instance. Each to his own, I guess.

If you are not going to use HTML generation capabilities of CGI.pm, you
should use something like CGI::Minimal.

Just a little explanation: The question is not whether CGI.pm is the
greatest thing since sliced bread. Most inexperienced programmers opt
for the handrolled solution instead of using CGI.pm (or a comparable
module) for processing forms. They seem to repeat all the same mistakes
with minor variations. They seem to be unaware of the CGI specs. So on
and so forth. Hence, my statement that "in most cases, it is a mistake
not to use CGI.pm".

Hence, the general consensus in this group, that if you are going to ask
a question about a Perl program designed to run in a CGI environment,
you'd better not be using a buggy home-brewed form processing routine.

CGI.pm has the advantage of being included in the core distribution, has
gone through many rounds of bug fixing etc.

Sinan

 

[John Bokma]

I see. This could get quite confusing for newbs I guess!

Yes, it can take some time to discover who is who in a newsgroup, and even
then, not all regulars think the same, or agree on everything

Some Usenet clients provide scoring (Xnews, Dialog, slrn), and at times it
can be useful to give a high score to people you consider skilled

 

[Matt Garrish]

Real problem is this new generation of brainwashed Perl minions, most
have no clue now to write code with their high dependency upon modules
and displayed syntax; Plug & Play Babies.

The world can only be so fortunate that no one uses your code. Most people
who recommend CGI.pm recommend it for it's parameter handling, not for the
rest of the bloat. I've never yet heard anyone recommend using CGI.pm over a
templating system and doubt I ever will.

It's an easy and ineffective argument to claim that that bloat somehow makes
the rolling your own solution a better option, however. You've never yet
provided a rationale as to how you sitting at your computer writing code
that will be used on a site only you visit is better tested and more stable
than a module that comes as part of the core distribution and has been
real-world tested by thousands of programmers.

We've seen what one bad programmer with your attitude toward cgi programming
can do. His name was Matt Wright and his formmail is still, I believe, one
of (if not the) most exploited program by spammers.

Matt

 

[Alan J. Flavell]

The world can only be so fortunate that no one uses your code. Most
people who recommend CGI.pm recommend it for it's parameter
handling,

I'll go along with that... (except it's its, not it's - SCNR)

not for the rest of the bloat. I've never yet heard anyone recommend
using CGI.pm over a templating system and doubt I ever will.

In general, a form is going to consist of some form elements
interspersed with text and HTML markup. There are situations where
CGI.pm is handy for generating that, including any sticky parameters
and so on. It's particularly useful for a design which rejects
erroneous input by redisplaying the same form, with the good inputs
pre-entered, and the defective input(s) flagged in some way, ready for
another try by the user. Trying to hobble to-and-fro between
CGI.pm-generated form elements with their parameters, and
template-generated text and markup, doesn't seem a lot of fun.
Unless you can show better.

However, I really wouldn't choose CGI.pm's HTML-generating methods for
generating the rest of the HTML for a web page, outside of the area of
a form - that much is true enough.

It's an easy and ineffective argument to claim that that bloat
somehow makes the rolling your own solution a better option,
however.

Having seen all the things which can go wrong with hand-rolled CGI
scripts, I wouldn't trust myself to get it right. In fact, I'd far
rather leverage the years of experience, peer review and testing which
have gone into modules such as CGI.pm, quite apart from the fact that
any bugs that come to light in the future are going to get fixed
without much effort on my part, which is a lot more than can be said
for anything that I might hand-roll for myself.

If the code is too inefficient for the production requirements as a
conventional CGI script, then there are well-exercised solutions for
speeding-up, *without* having to forgo the benefits of peer review and
extensive testing which are incorporated in the module.

cheers

 

[Matt Garrish]

I'll go along with that... (except it's its, not it's - SCNR)

Yes, I've made many grammatical blunders today to go along with some
incomplete posts (too little sleep). For some reason with usenet I'm more
inclined to send off a message without double-checking what I've written (I
noticed a programmer's instead of programmers' in one of my posts, but that
might be in another thread).

Matt

 

[John Bokma]

Well obviosuly I aim not to be in the "most" category if this category
is not using XHTML for what it was designed to do.

What advantages does XHTML give you over HTML?

I believe if I use
XHTML it is a clean and well formatted way of implementing my site and
with the use of CSS will keep things sharp, as far as accessibility
and validation is concerned!

How does HTML 4.01 fail at this?

I definitely agree things should be done properly though

Yup, a good starting point might be:
<http://www.hixie.ch/advocacy/xhtml>

 

[Gunnar Hjalmarsson]

Most people who recommend CGI.pm recommend it for it's parameter
handling, not for the rest of the bloat. I've never yet heard anyone
recommend using CGI.pm over a templating system and doubt I ever
will.

Probably true.

That's why one of the light-weight alternatives should be made a
standard module, and people should start recommending that module at
first hand instead.

 

[Gunnar Hjalmarsson]

If the code is too inefficient for the production requirements as a
conventional CGI script, then there are well-exercised solutions for
speeding-up, *without* having to forgo the benefits of peer review and
extensive testing which are incorporated in the module.

To many users of Perl scripts for the web, such solutions (e.g.
mod_perl) are not available without a costly upgrade of their web
hosting solution. Consequently I personally often use my own code instead.

At the same time, I usually recommend beginners to use CGI.pm. For the
sake of convenience. It's pretty time consuming to learn enough about
the HTTP stuff to get it right without a module.

 

[John W. Kennedy]

Why would you use XHTML? Most people who use it don't offer it to clients
("browsers") in the correct way.

....which they can't, so long as Microsoft refuses to support it.

--
John W. Kennedy
"You can, if you wish, class all science-fiction together; but it is
about as perceptive as classing the works of Ballantyne, Conrad and W.
W. Jacobs together as the 'sea-story' and then criticizing _that_."
-- C. S. Lewis. "An Experiment in Criticism"

 

[John Bokma]

...which they can't, so long as Microsoft refuses to support it.

IIRC this depends on the exact version of XHTML. And if I am wrong, it has
been a while since I decided to switch back from XHTML to HTML 4.01 strict.

 

[John W. Kennedy]

IIRC this depends on the exact version of XHTML. And if I am wrong, it has
been a while since I decided to switch back from XHTML to HTML 4.01 strict.

As far as I can determine, IE, through IE6, simply refuses to process
anything served as XHTML. If you serve XHTML as "text/html", it will
treat it as HTML 4. If you serve XHTML as "text/xml", it will
prettyprint it as XML source code, but won't format it.

(Bizarrely, my particular system is configured in such a way that, if IE
is directed to an XHTML page served as XHTML, it downloads it and then
invokes Firefox to display the local copy. Of course, the local copy is
missing all external styles, scripts, images, etc., so it's usually
pretty much useless.)

 

[John Bokma]

As far as I can determine, IE, through IE6, simply refuses to process
anything served as XHTML. If you serve XHTML as "text/html", it will
treat it as HTML 4.

Yup, and hence, for the lowest version of XHTML serving it as text/html to
IE is ok, and doing stuff like <img .... src="picture.jpg" /> so the parser
of IE doesn't choke on it.

But it's all weird hackism. One reason I wanted to use XHTML was that I was
looking into XSLT to create my site. Now I use my homebrew Perl stuff which
outputs HTML 4.01 strict.

As a sidenote, wrt the above, CGI.pm defaulting to XHTML (IIRC) is quite
wrong it broke a lot of stuff.

 

[Alan J. Flavell]

...which they can't, so long as Microsoft refuses to support it.

That depends on whether you're forced to take a business decision
to care about a browser-like object which disqualifies itself as
a WWW-compatible browser by violating some mandatory requirements
of the interworking protocols.

Personally, I find HTML4.01 quite adequate for web purposes, and can't
see any reason yet for deploying XML-based markups in production on
the web, no matter what their attractions for internal working.

But I could sympathise with those who want to do so, if they have some
good reasons (MathML, embedded SVG, whatever).

Sorry, what's this got to do with Perl?

 

[Alan J. Flavell]

Yup, and hence, for the lowest version of XHTML serving it as
text/html to IE is ok,

That depends on your interpretation of "ok". Only if you carefully
observe the restrictions of XHTML/1.0-Appendix C; and, even then, you
are relying on an SGML bug in the popular WWW browsers, as well as in
MSIE.

emacs-w3 had to be deliberately broken (it used to handle this SGML
feature correctly, unlike almost all other HTML browsers) to get the
intended results with "Appendix C" crud.

 

[John Bokma]

That depends on your interpretation of "ok". Only if you carefully
observe the restrictions of XHTML/1.0-Appendix C; and, even then, you
are relying on an SGML bug in the popular WWW browsers, as well as in
MSIE.

:-D. Yup.

emacs-w3 had to be deliberately broken (it used to handle this SGML
feature correctly, unlike almost all other HTML browsers) to get the
intended results with "Appendix C" crud.

OTOH, similar hacks are in use with CSS. One reason I don't like the
current use of CSS much. Quite some sites rely a lot on parsing bugs in
browsers for browser sniffing. I hope that MS finally does a good job with
IE7.

 

[Matt Garrish]

You need to lay down your gun, boy.

Laying down my gun won't level the playing field for you or her. Only a fool
such as yourself enters a battle of wits unarmed...

Matt