Perl 5.20 and CGI

[ccc31807]

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

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

Thanks, CC.

 

[Peter Makholm]

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

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

If CGI.pm 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 CGI.pm 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 CGI.pm the HTML::Tiny module seems
close to the concepts of CGI.pm, but it has been years since I have used
CGI.pm for generating HTML. Personally I prefer Template::Toolkit which
is quite another way to do it.

//Makholm

 

[Jim Gibson]

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

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

Lightning talk from German Perl Workshop, presenter not recorded but
said to be Sawyer X here:
<http://perltricks.com/article/92/2014/5/27/Perl-v5-20-what-you-need-to-
know>

(go to 5:48 near the end):

<

>


Advice:

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

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

(Probably Dancer)."

 

[Rainer Weikusat]

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

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

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.

http://search.cpan.org/dist/perl-5.20.0/pod/perldelta.pod#Module_removals

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.

 

[Rainer Weikusat]

[...]

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.

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.

 

[ccc31807]

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.

Yeah, I hear you. I typically tend to use tools (and create applications) that are crude, simple, and primitive. Like CGI, for example. I'm comfortable 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, say, an ascii file as HTML.

Some of the crude, simple, and primitive tools that I use a lot are the command interpreter (on Windows, too), vi/Vim, Perl, LaTeX, R (it originated in 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 jQuery, some R packages (e.g., ggplot2), git, etc.

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

CC.

 

[George Mpouras]

Στις 3/6/2014 18:26, ο/η ccc31807 έγÏαψε:

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

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

Thanks, CC.

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

 

[ccc31807]

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

George,

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.

CC.

 

[Scott Bryce]

I do not need any godzilla framework to think for me.

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?

 

[George Mpouras]

Στις 4/6/2014 16:14, ο/η Scott Bryce έγÏαψε:

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?

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

 

[Scott Bryce]

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

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
framework?

 

[Cal Dershowitz]

[...]

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.

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.

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:

http://www.imdb.com/title/tt0062362/?ref_=nv_sr_1

I use "contemporary" instead.

 

[Scott Bryce]

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

I am coming to the same conclusion.

Dancer, and other similar frameworks seem to be intended for use to
develop apps that do one task or a group of related tasks and are fairly
stable once they are released. I maintain web sites made up of hundreds
of scripts that each do one very targeted task, and are continually
under development. It seems like it would be a pain to do this under PSGI.

I found an example that uses Plack::Request and Plack::Response. The
docs discourage their use directly, but it seems cleaner than using a
framework built on top of them. Doing a little digging, it seems that
the server needs to be reconfigured and restarted each time a new app is
uploaded. This is more trouble than using CGI, which only requires a new
script to be uploaded to the server and the permissions set, especially
in an environment where new scripts are continually being added to the site.

So, it looks like I am sticking with CGI, at least for the short term. I
am looking at CGI::Minimal and CGI::Cookies to replace CGI.PM. With the
exception of parsing cookies, even CGI::Minimal does more than I need it to.

I usually develop in three phases:

1) Scripts are written to run outside of the HTTP environment. Inputs
are hard coded into the script and output is sent to a file, sans
headers. The file is opened in an appropriate viewer.

2) Once it is working properly, the script is tweaked to allow it to run
in an HTTP environment, and tested locally. Hard coded inputs are REMed
out, and the output is sent to the server/browser.

3) After it works in the HTTP environment, the script is uploaded to a
web server.

CGI.PM allows for this type of development easily. CGI::Minimal and
CGI::Cookies will require some extra tweaking of the script. It seems
that CGI::Minimal will lock up if is is not run in an HTTP environment.
CGI.PM does not. And CGI::Cookies will throw an error if I try to get
the value of a non-existing cookie. CGI.PM simple returns a NULL value.
A slight re-write of my boilerplate will take care of that problem.

If any of my observations are wrong, or my conclusions don't make sense,
I am open to input from those who are better at this than I am.

 

[Rainer Weikusat]

I am coming to the same conclusion.

Dancer, and other similar frameworks seem to be intended for use to
develop apps that do one task or a group of related tasks and are fairly
stable once they are released. I maintain web sites made up of hundreds
of scripts that each do one very targeted task, and are continually
under development. It seems like it would be a pain to do this under
PSGI.

Minus a few procedural infelicities you observed, eg, the inability to
exchange just a small part of 'the combined application', that's just a
different way to structure 'an application' (here refering to the
total functionality of 'the web site'): You're accustomed to CGI which
means that you build 'the web site' as a set of independent,
(presumably) cooperating programs and don't waste time worrying about
'creating processes to run programs' and the overhead is really usually
negligent on systems (like Linux) where 'process creation' is 'fast'
(after all, people used this model to build complex applications used by
relatively large numbers of users running on hardware which would seem
very puny when compared with current smartphones).

But there's also the competing (and actually older since it is really
'classic mainframe programming') approach that 'The Computer' executes
'The Program' (which is only started once, hence, the amortized cost of
process creation and program execution is zero) and 'The Program'
provides all required functionality via 'sub-programs' which are
integral parts of it. Other benefits of that would be that 'sharing
infrastructure code' is easier this way (since everything is part of a
single program, any subroutine can invoke any other subroutine) and that
different parts of 'the program' can cooperate by using 'shared
variables' instead of 'some IPC mechanism' (be it only creating files on
the file system). It is also easier to deal with by (relatively)
inexperienced programmers because 'add some more code to the existing
program in order to provide yet another feature' is a more
straight-forward operation than 'write a new program to do that' (and
integrate it into the existing environment in a way which requires using
tools other than "The Programming Language" and libraries written in it
which are also part of 'The Program').

NB: I usually prefer the first approach, however, everything I've ever
done via CGI was 'rather simple', while the most complex web application
I'm dealing with is a single, large 'frameworked' Java program (I'm also
dealing with things other than web application and have built some
pretty complex things from relatively simple, indepdendent parts, but
this may not be comparable).