GPW2014 S1E11.5: Lightning Talks - CGI pm must die! - Sawyer X
Why Stack Overflow recommends it
Stack Overflow users link it when answering Perl web questions that rely on CGI.pm, to explain why the module is obsolete and to point people toward Plack and frameworks like Dancer2, Mojolicious or Catalyst.
Recommended by 1 people across 6 different months, 2015 to 2018.
What it is
A roughly six minute lightning talk by Sawyer X, then Perl's release manager, given at the 2014 German Perl Workshop in Hannover. It argues that the CGI.pm module is outdated and should be replaced by modern PSGI/Plack-based web frameworks.
What people said
Recommends simbabque · 2015-06 · Stack Overflow · on “Input parameter for perl CGI script”
Check out SawyerX's talk *CGI.pm must die!*, which is extremely entertaining and shows why CGI is outdated: [this video] - of course you can still use it, but take into account that there are way easier things around today. :)
Recommends simbabque · 2016-08 · Stack Overflow · on “Multiple CGI Perl scripts”
If you are concerned about _separation of concerns_, don't go with CGI. Watch this lightning talk [this video] and then use a PSGI/Plack webframework. It's more modern, easier to implement and maintain, and you can still do your separation. The key point is you separate using modules that produce and consume. Then you bundle them in one application. If you still want it to be CGI, bundle those modules in one CGI script. But don't try to do multiple programs. That's going to be hell to set up and maintain. It's not how stuff is done.
Recommends simbabque · 2016-11 · Stack Overflow · on “cannot read cookie after setting it”
I've probably linked you this before, but you should watch it again. Sawyer X explaining why _CGI.pm must die_ [this video] at our German Perl Workshop in Hannover in 2014. Also, come to the next one in Hamburg!
Recommends simbabque · 2017-01 · Stack Overflow · on “Generate HTML form and process it in one PERL/CGI file”
The HTML generation from CGI.pm has been deprecated recently [LINK] and CGI.pm has been removed from the core [LINK] . If your environment only supports CGI, you should still use a Template engine like Text::XSlate [LINK] instead of this ugly wall of escaped HTML. Watch this talk [this video] to see what I mean.
Recommends simbabque · 2017-05 · Stack Overflow · on “jQuery Login - What is the best practise for a login?”
If you want it modern and you know Perl, you should look into some modern frameworks that work with PSGI/Plack. Start out with this talk [this video] and then look at the various frameworks, like Dancer2 [LINK] , Mojolicious [LINK] or Catalyst [LINK] . All of them have extensive documentation and a strong community. It will greatly make your life easier to use one of them instead of CGI.
Recommends simbabque · 2017-11 · Stack Overflow · on “perl avoiding of the "HTML Generation function"”
Your first script writes HTML directly. That's _not_ using the HTML generation functions. The second one uses them. I would prefer the first version, but it's still ugly. I suggest you watch this lightning talk [this video] by SawyerX.
Recommends simbabque · 2017-11 · Stack Overflow · on “My Perl code does not seem to work with .lib?”
Welcome to Stack Overflow and the Perl tag. It seems you are learning Perl from a _very_ out of date resource. Please take a look at the tag wiki [LINK] , where a lot of good, modern tutorials are mentioned. Next, please consider that CGI is an obsolete technology. It sure still works, but if you want to do something serious with the web, there are technologies that work better and make your life easier as a developer. I suggest to watch this talk [this video] by the current release manager of the Perl programming language.
Cites Pavel · 2015-05 · Stack Overflow · on “How to handle POST request to PERL from html”
Borodin [LINK] 's answer says all. Basically, you don't need the CGI.pm overhead [this video] : #!/usr/bin/perl -T use strict; use warnings; my %form; if ($ENV{REQUEST_METHOD} eq 'POST') { read(STDIN, my $form_data, $ENV{CONTENT_LENGTH}) or die "$!\n"; # URL decode chomp($form_data); $form_data =~ tr/+/ /; $form_data =~ s/%([a-f0-9][a-f0-9])/chr(hex($1))/egi; foreach (split /&/, $form_data) { # trim spaces s/^\s+|\s+$//g; # get the URL param my($key, $value) = split(/=/, $_, 2); $form{$key} = $value || ''; } } a dichotomy HTML <input type="text" name="email" /> CGI my $email = $form{email};
Cites darch · 2015-10 · Stack Overflow · on “Using perl REST::Application to parse url query string”
I could, but I'll let SawyerX do it: [this video] . As for alternatives, I'd love to offer one -- but I just found that `REST::Application` is based on `CGI`, so the question is moot.
Cites simbabque · 2016-12 · Stack Overflow · on “Accept POST parameters with FCGI”
You can't use CGI.pm [LINK] and FCGI.pm [LINK] together like this. You need some glue-code in between, because CGI needs to read stuff from the environment, and it can't in the way you invoke it. There is a module CGI::Fast [LINK] included with Perl that does this for you. Instead of using CGI [LINK] and FCGI [LINK] , you just use CGI::Fast [LINK] and change a bit of code. use strict; use warnings; use CGI::Fast; my $count; while (my $q = CGI::Fast->new) { # $q is a fresh CGI object for the current request print("Content-type: text/html\r\n\r\n", ++$count); print "name = " . $q->param("name") ; print "\n"; } If you already have a CGI script, you could put that in a function and call it insid