Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^12: Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?

by Anonymous Monk
on Nov 06, 2013 at 21:21 UTC ( #1061484=note: print w/ replies, xml ) Need Help??


in reply to Re^11: Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?
in thread Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?

No, it's still not correct and mixing the two approaches increases the cognitive load/overhead and potential bugs. You insist your future devs be adept at a dead-end and the idiosyncrasies that made it such instead of embracing ideas that span several high-level languages ... You also gloss the fact that once one knows enough to be able to wrap CGIs to PSGI, which isn't always easy or possible, one knows better than to write the stuff that needs to be wrapped in the first place.

Now that is even more ridiculous than your previous statement

You can write crap for every backend. The difference between CGI and PSGI is trivial , there is no cognitive load
sub psgier { my( $env ) = @_; my $req = Plack::Request->new( $env ); my $query = $req->param('query'); my $res = app_logic( $query ); return $res; }
sub cgier { my $q = CGI->new; my $query = $q->param('query'); my $response = app_logic( $query ); print $q->header; print $response; }

If you used any kind of abstraction like CGI::Application... then there is no difference of any kind between running on PSGI or CGI

PSGI is great, bashing CGI is weak


Comment on Re^12: Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?
Select or Download Code
Re^13: Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?
by Your Mother (Canon) on Nov 07, 2013 at 01:00 UTC

    Sorry for the misunderstanding, I will reword. I didnít bash CGI and if you knew me youíd realize Iím an apologist for it and have answered many, many questions here with code using it.

    My point is: itís basically perl4, mixes concerns too much (controller and view and even model and webserver, as implied in this threadís proxying answers), and has nearly nothing but godawful usage examples in the wild. There is a real drag on learning and grandfathered-gotcha-time that could be spent learning and improving newer stuff. zentaraís Vars bug in this thread is on point. Iím advocating choosing modern tools because they are easier, facilitate learning and sharing across other languages like Python, and are tremendously more friendly to plug-n-play extensibility.

    A good work environment is going to practice some parsimony with its tools and frameworks. Using Dancer AND Mojolicious AND CGI::Application AND Amon AND Catalyst AND raw Plack AND CGI is not the way to run a shop with multiple devs. CGI being the oldest and least well abstracted should be right out.

    I already said I use and will continue to use CGI for personal stuff, testing, terse code answers here, and guaranteed one-offs; itís still in my default code template. Far from bashing it, I love it. Iím giving what I feel is good advice and the kind of thing that would make the average Perl web development career better; including mine.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1061484]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (9)
As of 2014-09-22 07:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (182 votes), past polls