[Melbourne-pm] CGI quirks and other lightweight web-tools

[Andrew Solomon]

[Oops - copying the list this time]

I last used CGI over 5 years ago. On moving to Catalyst I found I
wasted less time focussing on the low level details. That said,
working at such a high level of abstraction came with its costs too.
Dancer2 is now my preference and I find it to be a nice middle-ground.
These days if you want to operate at the low level, Plack is probably
the way to go. And the good thing is that you can treat Plack as
middleware and let the simple requests percolate up to
Dancer/Catalyst/Mojolicious or whatever takes your fancy.


https://metacpan.org/pod/CGI#CGI.pm-HAS-BEEN-REMOVED-FROM-THE-PERL-CORE

https://metacpan.org/pod/CGI::Alternatives

http://advent.plackperl.org/2009/12/day-10-using-plack-middleware.html


Andrew

On Thu, Jan 8, 2015 at 10:44 PM, Mathew Robertson
<mathew.blair.robertson at gmail.com> wrote:
> Hi PM,
>
> In the thread discussing CGI, mod-perl and other frameworks, I thought it
> might be worth discussing the good/bad points of CGI, and/or other
> lightweight web-tools.  Am interested in other peoples thoughts.
>
> Generally speaking whenever I use a framework, in particular web-frameworks,
> they dramatically simplify about 80% of the workload - at the expense of
> making the last 20% near-impossible to work around.
>
> eg:
> - Catalyst about 5 yrs ago, was pretty good for its time at integrating
> database I/O - unless you had a table with a multi-column primary key.
> - Anything with Java Spring - yay for a few lines of code to handle CRUD;
> boo for knowing which config/xml file to modify just to set it up first time
> - Java Hibernate v2 and v3 - again multi-column primary keys.
>
> As such, my gut-feel is that "there be dragons whenever a framework is
> used".
> On the other hand "Libraries are awesome".
>
>
> A similar discussion has taken place around bless() vs using Moose, et al.
>
>
> So stepping back to learn from what we know... and since CGI.pm started this
> discussion...
>
> Good bits :
> -  param(), url_param(), cookie()
>
> Bad bits:
> -  param and url_param ... why isn't there a way to get all params...
> - it would be nice if CGI could work a little nicer with Getopt::Long so
> that in non-GATEWAY_INTERFACE mode, it would use command-line arguments
> [... sounds like a useful module idea ! ]
> - the whole "html shortcuts" thing.
>
>
> Other people's thoughts on CGI.pm?
> What other "basic tools" really help you get your work done?
>
> cheers,
> Mathew
>
>
>
> eg: I have this that I load up in almost every bit of code that I write, so
> that it gives me some (more!) globals, and sets $0 to be "$perl_script"
> (instead of "perl $perl_script").... Obviously doing this everywhere comes
> with a start-up cost.
>
> package Lib;
> BEGIN {
>   $TIME0 = [gettimeofday];
>   $BASENAME = basename($0);
>   $BASEPATH = abs_path(dirname($0)) || "";
>   $BASEPATH = '/' unless (length $BASEPATH);
>   $FULLNAME = $0 =~ /^\// ? $0 : ($ENV{PWD} ? $ENV{PWD}."/".$0 : $0);
>   $FULLNAME = canonpath($FULLNAME) || "";
>   while ($FULLNAME =~ /\.\./) {
>     $FULLNAME =~ s/\/?[^\/]*?\/\.\.//;
>   }
>   $DIRNAME = "".$FULLNAME;
>   $DIRNAME =~ s/\/$BASENAME$//;
>   $DIRNAME = '/' unless (length $DIRNAME);
>   if (!$ENV{GATEWAY_INTERFACE} && !$ENV{MOD_PERL}) {
>     lib->import($BASEPATH);
>     $0 = "$BASEPATH/$BASENAME".(@ARGV == 0 ? "" : " ".join(" ", at ARGV));
>     eval {
>       require Sys::Prctl;
>       Sys::Prctl::prctl_name($BASENAME);
>     };
>   }
> }
>
>
> _______________________________________________
> Melbourne-pm mailing list
> Melbourne-pm at pm.org
> http://mail.pm.org/mailman/listinfo/melbourne-pm



-- 
Andrew Solomon

Mentor at Geekuni http://geekuni.com/
http://www.linkedin.com/in/asolomon