I hate CGI.pm
Ben Bullock
use CGI.pm. It's a core module, something distributed with Perl, and
yet it's painful to use. I started out using CGI.pm a few years ago
when I knew next to no Perl, and at the time I blamed myself for the
module's unuseability. Since then I've been learning more and more
Perl, and yet coming back to CGI.pm I find that it's just as unuseable
to me now as it was then. Some of its behaviours are just stupid and
extremely annoying.
What do other people think of it? Am I a lone CGI.pm hater, or do
other people use some superior system instead of CGI.pm?
I tried to read the documentation for Catalyst, and it makes no sense
to me - it looks like you have to buy a book and spend hours and hours
to understand it. Since I don't usually even write web things, I don't
want to spend a lot of time studying the systems - I just want a
"better CGI module". Does it exist?
Brad Baxter
I've had good success with CGI:Minimal. http://search.cpan.org/dist/CGI-Minimal/
You have to bake your own cookies.
--
Brad
Gunnar Hjalmarsson
It depends on what you mean by "painful", "unusable", "stupid",
"annoying" and "better".
Personally I tend to avoid CGI.pm because it's slow. As regards parsing
form data, there are several alternative modules available, e.g.
CGI::Lite and CGI::Minimal.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
Mirco Wahab
Hi Ben,
I almost always use HTML::Template and use CGI
only sometimes for POST/GET parameter extraction
and url encoding (seems to work). I tend to give
the html-template exactly the same name as the
corresponding Perl script and change the extension
to htm (by convention: .htm is template, .html
is static content).
If HTML::Template doesn't fit, I use HTML::Mason
(but that's only on somehow complicated things).
Regards
M.
brian d foy
<benkasmi...@gmail.com> wrote:
> Today I wanted to write a web interface for something, and I opted to
> use CGI.pm. It's a core module, something distributed with Perl, and
> yet it's painful to use.
I think you'd need to define "painful to use". What was painful? What
did you have trouble doing?
Ron Bergin
> Today I wanted to write a web interface for something, and I opted to
> use CGI.pm. It's a core module, something distributed with Perl, and
> yet it's painful to use. I started out using CGI.pm a few years ago
> when I knew next to no Perl, and at the time I blamed myself for the
> module's unuseability. Since then I've been learning more and more
> Perl, and yet coming back to CGI.pm I find that it's just as unuseable
> to me now as it was then. Some of its behaviours are just stupid and
> extremely annoying.
>
> What do other people think of it? Am I a lone CGI.pm hater, or do
> other people use some superior system instead of CGI.pm?
>
I think CGI.pm is an excellent module and fairly easy to use once you
thoroughly read the documentation. However, it's not perfect, but
then nothing is ever perfect.
If you truly believe that it's that bad, why don't you write/publish
your own version, rather than simply complaining without specific
details and examples.
xho...@gmail.com
> Today I wanted to write a web interface for something, and I opted to
> use CGI.pm. It's a core module, something distributed with Perl, and
> yet it's painful to use. I started out using CGI.pm a few years ago
> when I knew next to no Perl, and at the time I blamed myself for the
> module's unuseability. Since then I've been learning more and more
> Perl, and yet coming back to CGI.pm I find that it's just as unuseable
> to me now as it was then. Some of its behaviours are just stupid and
> extremely annoying.
>
> What do other people think of it? Am I a lone CGI.pm hater, or do
> other people use some superior system instead of CGI.pm?
I like CGI.pm. I have been frustrated with it at times, but that
frustration was usually resolved when I tried to do the same thing myself
and thus discovered the subtleties involved, and then appreciated why CGIs
needlessly complicated approach wasn't so needless after all.
> I tried to read the documentation for Catalyst, and it makes no sense
> to me - it looks like you have to buy a book and spend hours and hours
> to understand it. Since I don't usually even write web things, I don't
> want to spend a lot of time studying the systems - I just want a
> "better CGI module". Does it exist?
Have you looked at CGI::Lite? I didn't consider it better last I looked at
it, but YMMV.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
David Filmer
> I hate CGI.pm
I hate php. I hate it when I must try to understand or modify someone's
php code. But the main source of my dislike is that I don't know php
very well at all. It's easy to be frustrated by something I don't
understand.
I really like CGI.pm, but there was a definite learning curve for me to
understand it (and I was frustrated when I was on the flat part of the
curve). It was worth the effort. I also bought the book (by Lincoln
Stein) which was helpful.
I use HTML::Template for all my webby stuff, but I write Perl programs
(using CGI.pm) to create the templates. Really.
--
David Filmer (http://DavidFilmer.com)
The best way to get a good answer is to ask a good question.
cartercc
> What do other people think of it? Am I a lone CGI.pm hater, or do
> other people use some superior system instead of CGI.pm?
> want to spend a lot of time studying the systems - I just want a
> "better CGI module". Does it exist?
I've been using Perl for about ten years for web programming. I took
one look at CGI and decided to 'roll my own.' I use CGI to pass
parameters from forms to scripts, but the big module that I find
absolutely essential is DBI.
When I develop a web project, I first start by building a module for
database connectivity and HTML components (like the header, footer,
buttons, menus, and so on.) I then build scripts that encapsulate
functionality depending on the data. A very rough sample of pseudo
code follows.
I initialize my variables and then use heredocs to spit out HTML. To
me, this is more intuitive than using any kind of includes tags, like
JSP, PHP, ColdFusion, Catlyst, etc.) You can use the http header of
the requested URL as a key into your database to dynamically generate
pages depending on the user input. Essentially, you are writing a
program to write a program to generate a website.
This is what I mean:
use strict;
use CGI;
use DBI;
use myHTMLmodule;
#passed in from an HTML form or from this script
my $what = param('what');
my $name = param('name');
my $number = param('number');
my $answer = param('answer');
#generate dynamic page based on content drawn from database
myHTMLmodule::header;
myHTMLmodule::menu;
&step_1 if $what eq 'Click Here';
&step_2 if $what eq 'Got Name';
&step_3 if $what eq 'Got Number';
&step_4 if($what eq 'Ask Question';
&error if $what eq '';
myHTMLmodule::return_home;
myHTMLmodule::footer;
sub step_1
{
print <<step1
<p>You want to $what</p>
<ul>
step1
my @results = myHTMLmodule::return_query_results($what);
foreach my $result (@results) { print "<li>$result</li>"; }
print <<step1
</ul>
<p>This is the remainder of step 1:</p>
<!-- HTML -->
step1
}
step2, step3, step4, and error similar
szr
> Today I wanted to write a web interface for something, and I opted to
> use CGI.pm. It's a core module, something distributed with Perl, and
> yet it's painful to use. I started out using CGI.pm a few years ago
> when I knew next to no Perl, and at the time I blamed myself for the
> module's unuseability. Since then I've been learning more and more
> Perl, and yet coming back to CGI.pm I find that it's just as unuseable
> to me now as it was then. Some of its behaviours are just stupid and
> extremely annoying.
Could you be kind enough to provide an example or two where CGI.pm
didn't work well for you? Everyone can have a different experience so it
might help to know where you're coming from via illustration :-)
Also please see my reply to your posting in the related FAQ thread.
--
szr
Ted Zlatanov
BB> What do other people think of it? Am I a lone CGI.pm hater, or do
BB> other people use some superior system instead of CGI.pm?
mod_perl does most of the things I need (with Template Toolkit). For
quick tasks, I like CGI::FormBuilder. I don't hate CGI.pm, just haven't
found a compelling reason to use it instead of those two. A few times
I've had to import utility functions, but that's about it.
Ted
Joe Schaefer
> I tried to read the documentation for Catalyst, and it makes no sense
> to me - it looks like you have to buy a book and spend hours and hours
> to understand it. Since I don't usually even write web things, I don't
> want to spend a lot of time studying the systems - I just want a
> "better CGI module". Does it exist?
>
The Apache folks, myself included, got together to write libapreq2,
which provides APR::Request::CGI. Installing the module is a pita,
because it depends on apache2 and mod_perl2 being installed. But
as far as features and performance goes there are few perl modules
capable of matching it.
Migrating between APR::Request::CGI and APR::Request::Apache2 for
mod_perl2 is straightforward: just change the initial
APR::Request::CGI->handle() to APR::Request::Apache2->handle(). Otherwise
the behavior of the library should be identical between CGI and
mod_perl2.
One nice feature is that parameters and cookies are subclassable
objects, so you can change the FETCH behavior of the underlying
tables by changing their param_class or cookie_class. It's also
compatible with the basic param() API of CGI.pm, so you don't need
to read a whole lot of docs in order to make basic use of it.
--
Joe Schaefer
Leon Timmermans
> people use some superior system instead of CGI.pm?
>
I don't CGI is a bad system, and in the past I have used it on a number
of projects. It's form-handling is quite good IMHO. Having said that,
these days there are plenty of more capable system out there.
> I tried to read the documentation for Catalyst, and it makes no sense to
> me - it looks like you have to buy a book and spend hours and hours to
> understand it. Since I don't usually even write web things, I don't want
> to spend a lot of time studying the systems - I just want a "better CGI
> module". Does it exist?
>
Catalyst may or may not be an overkill for your needs, but I can't
recommend anything without knowing what you really want. Perhaps Jifty is
more like what you're looking for.
Cheers,
Leon
Charlton Wilbur
BB> What do other people think of it? Am I a lone CGI.pm hater, or
BB> do other people use some superior system instead of CGI.pm?
I think that using a widely available module to do something that's
fiddly and prone to subtle problems is almost always the right thing to
do. Parsing CGI parameters by hand is almost always the wrong thing to
do. I find that CGI.pm has a lot of extra baggage that I don't usually
need -- largely, the convenience methods for producing HTML, which are
just as hard to get right as actual HTML and one step removed from the
problem -- but I use it in preference to handrolling code.
BB> I tried to read the documentation for Catalyst, and it makes no
BB> sense to me - it looks like you have to buy a book and spend
BB> hours and hours to understand it.
Catalyst is a web application framework; to get anywhere meaningful with
it, you have to understand how it thinks. It's also built on the
TMTOWTDI principle, and so once you start involving plugins to do
things, you start running into many more ways to solve problems and thus
you need to understand more things to be able to make an intelligent
choice.
For large web applications, it makes sense to start with a framework.
For one-script pages, it makes far less sense.
BB> Since I don't usually even write web things, I don't want to
BB> spend a lot of time studying the systems - I just want a "better
BB> CGI module". Does it exist?
What do you need the module to do? What do you find painful about
CGI.pm?
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Peter J. Holzer
> Ben Bullock wrote:
>> Today I wanted to write a web interface for something, and I opted to
>> use CGI.pm. It's a core module, something distributed with Perl, and
>> yet it's painful to use. I started out using CGI.pm a few years ago
>> when I knew next to no Perl, and at the time I blamed myself for the
>> module's unuseability. Since then I've been learning more and more
>> Perl, and yet coming back to CGI.pm I find that it's just as unuseable
>> to me now as it was then. Some of its behaviours are just stupid and
>> extremely annoying.
>
> Could you be kind enough to provide an example or two where CGI.pm
> didn't work well for you?
* The param function doesn't deal well with non-ascii data. Newer versions
of CGI.pm can treat the parameters as UTF-8, but that's still not
flexible enough. So basically, you have to decode all parameters
manually.
* Constructing an URL with parameters is weird. It works, but I always
need the man-page and several attempts to get it right. Doing it
manually is a lot simpler (not just to write - also to maintain).
* I never found a use for the "html convenience functions". They are
slightly useful for prefilling forms with parameters (but only if you
use ASCII only, otherwise CGI.pm's lack of consistent encoding rules
will trip you up badly), but for anything else simply printing html is
simpler.
I do use CGI.pm. A lot. But only for very basic things like getting
parameters.
hp
xho...@gmail.com
> On 2008-06-23 18:06, szr <sz...@szromanMO.comVE> wrote:
> >
> > Could you be kind enough to provide an example or two where CGI.pm
> > didn't work well for you?
>
> need the man-page and several attempts to get it right. Doing it
> manually is a lot simpler (not just to write - also to maintain).
In what context is this? CGI.pm has tools for creating "self-referencing"
URLs, but I don't think CGI.pm presents itself as a generic URL creating
tool, so I'm not surprised it would be clumsy at doing that.
When making self-referencing URLs, it would be nice if there was a way to
say "Give me the self-referencing URL that would exist if this one
parameter had this value instead of what it actually does." In the absence
of that, I have to store the value, change it, get the self_url, then
change it back.
brian d foy
wrote:
> When making self-referencing URLs, it would be nice if there was a way to
> say "Give me the self-referencing URL that would exist if this one
> parameter had this value instead of what it actually does." In the absence
> of that, I have to store the value, change it, get the self_url, then
> change it back.
When I want to do that, I create a second CGI.pm object. I can change
it how I like without affecting the original data.
Joseph Brenner
Charlton Wilbur <cwi...@chromatico.net> writes:
> I find that CGI.pm has a lot of extra baggage that I don't usually
> need -- largely, the convenience methods for producing HTML, which are
> just as hard to get right as actual HTML and one step removed from the
> problem -- but I use it in preference to handrolling code.
The advantage would be that a missing closing tag becomes a perl
syntax error, and is caught by the compiler.
But that doesn't get you the separation of code and content that's the
modern style for web apps.
In general, CGI.pm seems both old-fashioned and bloated. It
probably should've been "deprecated" some time ago...
Sherman Pendley
> Charlton Wilbur <cwi...@chromatico.net> writes:
>> I find that CGI.pm has a lot of extra baggage that I don't usually
>> need -- largely, the convenience methods for producing HTML, which are
>> just as hard to get right as actual HTML and one step removed from the
>> problem -- but I use it in preference to handrolling code.
>
> The advantage would be that a missing closing tag becomes a perl
> syntax error, and is caught by the compiler.
That's not much of an advantage, IMNSHO - not enough to compensate for
the lack of separation you mention in your second point:
> But that doesn't get you the separation of code and content that's the
> modern style for web apps.
Indeed.
> In general, CGI.pm seems both old-fashioned and bloated. It
I think that the bloat is actually much less than many people think it
is. The HTML generation methods are autoloaded, so they literally
don't exist until you call them. So unless you're actually using them,
the memory footprint and startup time of a CGI is pretty much the same
as it would be if they weren't available.
> probably should've been "deprecated" some time ago...
While it hasn't been formally deprecated or removed from the core set
of modules, I think CGI.pm's use has been declining for quite some
time now, along with the use of external one-shot CGI apps. Nowadays,
most of the "serious" use of Perl on the web is done in a persistent
environment such as mod_perl or FastCGI.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net