Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Alternative to CGI.pm

by sectokia (Acolyte)
on Mar 24, 2017 at 08:59 UTC ( #1185731=perlquestion: print w/replies, xml ) Need Help??
sectokia has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks, what is built in to perl dist these days that is meant to take the place of CGI.pm? Especially for the HTTP essentials like params and header?

Also whats with the apparent 'crusade' against CGI.pm? Removing it from dist is fine (great even), but it seems that someone is especially out to make it hard to even get installed. I had some older code to run and I noticed that:

  • Bigger dists (think Ubuntu) got CGI.pm on exclusion lists, even thought they package a pre-compiled version of pretty much everything on cpan. In particular its banned as a security threat?!
  • Someone seems to have 'minified' its build scripts on cpan. Previously I believe it had a mechanism that told you gcc/make wasn't installed. Now it just throws pages of errors that would be impossible to interpret for those who don't know about gcc/make.

Replies are listed 'Best First'.
Re: Alternative to CGI.pm
by hippo (Abbot) on Mar 24, 2017 at 09:23 UTC
    what is built in to perl dist these days that is meant to take the place of CGI.pm?

    Short answer: nothing. The philosophy seems to be that since CGI.pm is no longer the de-facto standard for such tasks and has some other drawbacks that it shouldn't be in core rather than there should be something to replace it. A quick search here will show you many discussions about this over the past couple of years so you can look there for the rationale. (Update: Here's one such discussion posted only last month, for example)

    My preference these days is for CGI::Lite. It has no non-core dependencies, is lighter (!) and faster than CGI.pm and doesn't require gcc to install because it is pure perl. There are plenty of other CGI implementations out there and there are also a bunch of framework-in-a-box options if you fancy that: Mojolicious, Dancer2, even Catalyst for the brave.

    Take some for a spin and see how you get on with them. Folks here will be able to give you ideas but it's a very personal decision which to use depending on whether you prefer speed, resilience, security, flexibility, etc.

      "and doesn't require gcc to install because it is pure perl."

      Just for clarity CGI doesn't need a c compiler:

      "To make this a little easier the CGI::Fast module has been split into its own distribution, meaning you do not need access to a compiler to install CGI.pm"

      " even Catalyst for the brave."

      For the Foolish.

Re: Alternative to CGI.pm
by Discipulus (Monsignor) on Mar 24, 2017 at 09:40 UTC
    Well, it is not a crusade but it's usage it is now discouraged: 20 years full of events are passed and CGI is no more the king of the dyanmic web.

    CGI was a specification and CGI.pm was it's implementation: the new shiny specification is now PSGI and Plack is the implementation by it's author.

    That said you can install CGI and you can use it if you understand well your needs and eventual drawbacks.

    You can be interested in the following video by SayerX (one of the author of Dancer2) CGI must die!

    See also perl as a php alternative 2015 and also CGI alternatives BIS lot of links and finally the recent UP-TO-DATE Comparison of CGI Alternatives - a 2017 Perl Web Panorama

    My homoenode if full of links about such alternatives; you are welcome at any time!



    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Re: Alternative to CGI.pm
by kbrannen (Beadle) on Mar 24, 2017 at 19:14 UTC
    I feel your pain since we do a lot of CGI where I work. It's fast and easy and I really don't have any complaints about it.

    An alternative to most of the CGI input parts would be CGI::Simple. It will give you params() and such just like CGI.pm did ... if you don't want to install CGI.pm yourself.

    For the output parts, there's HTML::Tiny. I haven't tried it but it's there if you want something like that.

    FWIW, I've looked at some of the PSGI frameworks and all the examples I've seen are pretty small and have so much overhead I don't see the advantage of them. I suppose I'd need to find more than "tutorial examples" to see what they really offer. Back in time, someone here created a few pages with Mojolicious and they are a real pain to maintain and seem to have a lot of "black magic" compared to CGI, creating a negative impression IMHO. In fact, we'll probably end up ripping out Mojolicious and converting those pages to CGI to simplify our software code base.

      IMHO. In fact, we'll probably end up ripping out Mojolicious and converting those pages to CGI to simplify our software code base.

      This comes off sounding a bit like: In fact, Perl 5.10 has so many weird conventions and features we don't use, we'll probably end up converting all our scripts back to 5.4.

        LoL :)

        It's meant in a practical way and more like: All of our programs are in Perl, except for a few that are in Python and no one here knows Python, so if we can get those translated to Perl then we can ditch the Python stuff and our code base will be easier to maintain because we'll have fewer technologies to know. (That was reality for us too until I rewrote the last Python program in Perl a few months ago.)

        In the abstract, there's nothing wrong with Python for those of you who like it. In the practical sense, it's an issue for us here because no one here knows Python so it makes our job harder.

        Since ~97% of our code is CGI, why maintain a vast minority of code in a framework no one here really knows and slows us down? (How did it get here? Someone wrote it as a proof of concept and then checked it in just before they left for another job and at the time there was no one to prevent that -- a sad tale.)
      "Back in time, someone here created a few pages with Mojolicious and they are a real pain to maintain ..."

      Without showing us what you are up against, we cannot really have a meaningful discussion.

        If the PSGI frameworks work for you and speed you up, that's really great and I'm happy it's a positive there.

        For us here, no one really knows Mojolicious, so it's a struggle to work on it when something goes wrong. Yes, we could invest the time to learn it, but it's only like 3% of our code and we have so many other important things to do.

        When we do have to work on the code, we find it hard to figure where/when things are happening or how it gets called. There appears to be a lot of "black magic". Now, if we understood the framework, it probably wouldn't be considered magic, but as it is, it looks like subs get called for no reason we can discern.

        I don't particularly like all the code that gets pulled in because of the framework, as in many thousands of lines in extra modules no one else uses, plus an extra service (I guess you'd call it): morbo. This appears to be a problem only because our entire app isn't written with Mojo. If it was, I probably wouldn't complain about it because it'd be used for everything. But when only a tiny amount of our app uses it, it seems like a large overhead.

        Mojo forces another templating system on us; we normally use Template Toolkit. OK, Mojo's templates aren't not overly hard to understand and there are even a few cool things about them, but the problem is that it's yet another exception to the rest of our code base.

        There are probably a few other issues, but those are the main ones. Sure, some of this you can throw into the category of "you don't like it because it's different" and I'll even agree. But a large part of my problem with Mojo is that I can't see the benefit the framework is supposed to give me ... the small examples in the tutorials don't strike me as "wow, that'd be so helpful". Maybe I haven't found the right tutorials. (shrug) It might be great tech, but I just haven't seen why. I'm open to understanding if someone can explain it.

        If you're wondering how did that bit of Mojo code get here, the answer is someone wrote it as a proof of concept and then checked it in just before he left for another job. At the time there were no controls in place to prevent that like there is now. It was also from before I started working here.

Re: Alternative to CGI.pm
by faraco (Acolyte) on Mar 24, 2017 at 16:15 UTC

    I like to use PSGI/Plack. It's simple enough to learn and to use, but most people don't use Plack from scratch anymore unless they are making a web framework or prefer their own way to do it. They usually go for higher level and 'out-of-the-box' options, like Dancer2 web framework in case they want to save time and cost. There's also Mojolicious (which has Mojolicious::Lite that is great for microservice web applications prototyping) that you need to try.

    Do you know how raccoons can be so slick at surviving?
      Here is an example of using Plack to capture form queries:
      use Data::Dumper; use Plack::Request; use Plack::Response; my $app = sub { my $req = Plack::Request->new(shift); my $query = $req->parameters; my $res = Plack::Response->new(200); $res->body('<pre>' . Dumper($query) . '</pre>'); $res->finalize; };

      Out of curiosity, I looked at the PSGI/Plack website and made an amusing discovery.

      Many years ago, before I "discovered" Perl, I wrote a webserver in AWK. It wasn't purely in AWK; I wrote a C program to listen for and accept incoming HTTP connections. It then read the request and "parsed" it into an array of name/value pairs, then exec'd AWK, using the array as the environment pointer.

      Seems I "invented" "ASGI". Not the same as PSGI, but very close.

        That sounds amazing! Any chance the codebase still lurking around somewhere?

        Do you know how raccoons can be so slick at surviving?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1185731]
Front-paged by Corion
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2017-12-16 19:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (458 votes). Check out past polls.

    Notices?