Perl 5.20 and CGI

Discussion in 'Perl Misc' started by ccc31807, Jun 3, 2014.

  1. ccc31807

    ccc31807 Guest

    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.
    ccc31807, Jun 3, 2014
    1. Advertisements

  2. 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.

    Peter Makholm, Jun 3, 2014
    1. Advertisements

  3. ccc31807

    Jim Gibson Guest

    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, Jun 3, 2014
  4. 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.
    Rainer Weikusat, Jun 3, 2014
  5. [...]
    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.
    Rainer Weikusat, Jun 3, 2014
  6. ccc31807

    ccc31807 Guest

    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.

    ccc31807, Jun 3, 2014
  7. Στις 3/6/2014 18:26, ο/η ccc31807 έγÏαψε:
    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.
    George Mpouras, Jun 4, 2014
  8. ccc31807

    ccc31807 Guest


    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.

    ccc31807, Jun 4, 2014
  9. ccc31807

    Scott Bryce Guest

    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?
    Scott Bryce, Jun 4, 2014
  10. Στις 4/6/2014 16:14, ο/η 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
    George Mpouras, Jun 4, 2014
  11. ccc31807

    Scott Bryce Guest

    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
    Scott Bryce, Jun 4, 2014
  12. 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.
    Cal Dershowitz, Jun 4, 2014
  13. ccc31807

    Scott Bryce Guest

    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.
    Scott Bryce, Jun 5, 2014
  14. 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).
    Rainer Weikusat, Jun 5, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.