Perl 5.20 and CGI

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I very occasionally do LAMP stacks with Perl, and I have always used, which has always worked well for me.

Now that Perl 5.20 has deprecated the, what is the more modern way to do this?

Thanks, CC.

Re: Perl 5.20 and CGI

Quoted text here. Click to load it

If works for you and you don't want to change the way you write
web code, then you will always be able to install the CGI module from
CPAN. (Well, as long as it is maintained and not actively removed).

IF solves your problems then you are not forced to switch away.

As for alternatives it depends on which parts you want to replace. For
larger web-application I would recommend looking at one of the larger
frameworks: Catalyst, Mojolicious, Dancer, ...

If you just want a simple interface for handling HTTP requests, then
Plack with Plack::Request might solve your problems satisfactory.

For the HTML generation parts of the HTML::Tiny module seems
close to the concepts of, but it has been years since I have used for generating HTML. Personally I prefer Template::Toolkit which
is quite another way to do it.


Re: Perl 5.20 and CGI

Quoted text here. Click to load it

Lightning talk from German Perl Workshop, presenter not recorded but
said to be Sawyer X here:  

(go to 5:48 near the end):



"Use a 'proper web framework' that supports PSGI:  

Catalyst, Dancer, Web::Simple, Mojolicious, etc.

(Probably Dancer)."

Jim Gibson

Re: Perl 5.20 and CGI

Quoted text here. Click to load it

    Module removals

    The following modules will be removed from the core distribution
    in a future release, and will at that time need to be installed
    from CPAN. Distributions on CPAN which require these modules
    will need to list them as prerequisites.
    The core versions of these modules will now issue
    "deprecated"-category warnings to alert you to this fact. To
    silence these deprecation warnings, install the modules in
    question from CPAN.

    Note that the planned removal of these modules from core does
    not reflect a judgement about the quality of the code and should
    not be taken as a suggestion that their use be halted. Their
    disinclusion from core primarily hinges on their necessity to
    bootstrapping a fully functional, CPAN-capable Perl
    installation, not on concerns over their design.

In particular, while the "scheduled-to-be-removed" list does reflect a
judgement about the quality of the code ('quality' really means 'the
nature of something', not some kind of affirmative verdict about this
nature) namely "It smells like UNIX(*) and I HATE (!!!!1) that", it
doesn't imply that the more traditional (as seen from the perspective of
197x) concepts supposed to provide an alternative have suddenly become
'modern' because their devoted followers are meanwhile to young to know
that they're actually traditionalist.

stupid adjectives must die (was: Perl 5.20 and CGI)


Quoted text here. Click to load it

Rant continued: I think I'm really tired of the adjective 'modern' in
itself. For most practical purpose, that fell out of use at the end of
the first third of the last century when the fact that the people who
used to label themselves as 'modern' didn't represent the ultimate
culimination of human cultural history couldn't be explained away any
longer and it really doesn't mean anything except someone asserting
that his opinions are inherently more valuable than someone else's
opinions because they're his opinions and not someone else's, IOW,
whoever uses it unironically is a common dimwit --- surely an ageless
human trait but most certainly not a new one.

Re: stupid adjectives must die (was: Perl 5.20 and CGI)

On Tuesday, June 3, 2014 4:38:28 PM UTC-4, Rainer Weikusat wrote:
Quoted text here. Click to load it

Yeah, I hear you. I typically tend to use tools (and create applications) t
hat are crude, simple, and primitive. Like CGI, for example. I'm comfortabl
e with the notion that I can get the values of certain variables via HTTP,  
and pass them to a program that will produce a particular kind of output, s
ay, an ascii file as HTML.

Some of the crude, simple, and primitive tools that I use a lot are the com
mand interpreter (on Windows, too), vi/Vim, Perl, LaTeX, R (it originated i
n the 1970s with S), Lisp, C, Apache, and so on. These all work well for me

On the other hand, there are some new tools that are just great, such as jQ
uery, some R packages (e.g., ggplot2), git, etc.

I think that the main thing is to use the best tool, whether it's ancient o
r modern. And I don't think that 'modern' is a pejorative term. Sometimes,  
something newer and better comes along, and sometimes something newer and w
orse comes along.


Re: stupid adjectives must die

On 06/03/2014 01:38 PM, Rainer Weikusat wrote:
Quoted text here. Click to load it

The problem with the word "modern" is that it becomes untrue the instant  
it's used and becomes increasingly-so as a function of time:

I use "contemporary" instead.

Re: stupid adjectives must die

Quoted text here. Click to load it

Huh. I was totally expecting it to be the page for this:

To further support your claim: Over at, you can't search
earlier than 1800, but there are over 20 results for that one year: [1800-01-01%20TO%201800-12-31]

Successful men of modern times (1800)

Chapter III is "Successful Engineers and Inventors" has dates going to
1821, suggesting the title page date is a lie, however. Still, the
principle discussion of the chapter is about events of the 1700s.

nothing about successful women in there, it seems

Re: Perl 5.20 and CGI

Στις 3/6/2014 18:26, ο/η ccc31807 έγραψε:
Quoted text here. Click to load it

i do not need any gozilla framework to think for me.
I want to print what I want where I want using
Do you want to talk about productivity for CGI vs gozilla-frameworks ? no problem.

Re: Perl 5.20 and CGI

On Tuesday, June 3, 2014 7:14:28 PM UTC-4, George Mpouras wrote:
Quoted text here. Click to load it


I totally agree! I habitually build my own custom framework for each web app I do. It's simple, crude, but does what I need and no more.

I've looked at some of the Perl frameworks, and really don't have the stomach for it. Yes, I really would like to have a conversation about the productivity for CGI versus Godzilla Framework.


Re: Perl 5.20 and CGI

On 6/3/2014 5:14 PM, George Mpouras wrote:
Quoted text here. Click to load it

I have been looking at Dancer, and I have come to the same conclusion.
All I need is a module that will parse the input from the client. I am
perfectly happy with HTML::Template and DBI. I don't need substitutes
for these written into the framework. One of the problems with CGI.PM is
that it does far more than you actually need it to do. Dancer is no
different in that regard. And I would have to modify some of my own
modules to work in a PSGI environment.

Are we just switching from one bloated method to another?

Re: Perl 5.20 and CGI

Στις 4/6/2014 16:14, ο/η Scott Bryce έγραψε:
Quoted text here. Click to load it

I also look at Dancer as a CGI alternative more than once.
So I come to the task to create some forms and drop down lists filled dynamic from DB  
tables. It is something that I am doing at CGI with blind eyes, and with Dancer is beyond  
headache. So the next move is ... CGI

Re: Perl 5.20 and CGI

On Wed, 04 Jun 2014 21:27:23 +0300, George Mpouras wrote:

Quoted text here. Click to load it

May I suggest Dancer::Plugin::SimpleCRUD? (disclaimer, I'm a contributor  
to DPSC).

I use (mostly with TT) or Dancer (with TT) when appropriate. Both  
are to heavy. Both are simple to use. Dancer needs Plack or needs to run  
stand-alone, which is IMO a big disadvantage when you just want something  
simple. With Dancer and plugins I can solve problems quickly. No need to  
write all that boilerplate, just focus on what you want to do.


Re: Perl 5.20 and CGI

On 6/4/2014 12:27 PM, George Mpouras wrote:
Quoted text here. Click to load it

Some, please, correct me if I am wrong, but Dancer appears to set up a
whole application environment for every script. I have a website that is
composed of hundreds of CGI scripts, each serving a specific purpose. It
would be insane to have a separate environment set up on the server for
each script.

Is there a simple way for a script to communicate with the server via
PSGI without all the additional whistles and bells of an application

Site Timeline