Re^2: using HTTP::Response directly to speak CGI

Thank you for the reply - I can see the reasoning behind your answer to my misplaced expectation "...expect to work..".

I suppose I expected, because I came across a few examples that I thought were using the HTTP::Response Object. I need to go look more as to what the CGI (which I presumed - shouldn't presume I know - would use the HTTP::Response) actually does when it writes out.

Incidentally, I read that the CGI is removed from core and no longer considered 'good practice' to use any more, being usurped by better ways allegedly.

Perhaps I should just stick to print statements and drive it myself as I don't necessarily always have access to compile install other modules so I am not able to use other than what's available.

Thank you again

Comment on Re^2: using HTTP::Response directly to speak CGI

Replies are listed 'Best First'.
Re^3: using HTTP::Response directly to speak CGI by Anonymous Monk on Jan 09, 2017 at 11:09 UTC
Perhaps I should just stick to print statements and drive it myself as I don't necessarily always have access to compile install other modules so I am not able to use other than what's available. No, "print statements" are what the complainers about CGI.pm are talking about If you're making "cgis" the CGI.pm module is the absolute bare minimum, it provides you with header function for generating the headers you want, cookies for cookies, and param function for getting the data None of the alternatives to CGI.pm for speaking CGI are as good as CGI.pm What you want to avoid is just print statements everywhere If you read CGI::Alternatives you can see what the people complaining about CGI.pm being backwards are really complaining about, and its not header/param, its the no organization , no subroutines/reuse, one shot style ... RAW For a bare minimum of contrast see cgi101 , sub RootPage, sub RootTemplate , ..., unclunky cgi, ... Contrast increases only a little bit with with CGI::Application .... If you're using CGI.pm and following CGI to mod_perl Porting. mod_perl Coding guidelines you're 98% modern , only 2% away from using any "modern frameworks" which have a response object	[reply]

Replies are listed 'Best First'.

Re^3: using HTTP::Response directly to speak CGI
by Anonymous Monk on Jan 09, 2017 at 11:09 UTC

Perhaps I should just stick to print statements and drive it myself as I don't necessarily always have access to compile install other modules so I am not able to use other than what's available.

No, "print statements" are what the complainers about CGI.pm are talking about

If you're making "cgis" the CGI.pm module is the absolute bare minimum,

it provides you with header function for generating the headers you want, cookies for cookies, and param function for getting the data

None of the alternatives to CGI.pm for speaking CGI are as good as CGI.pm

What you want to avoid is just print statements everywhere

If you read CGI::Alternatives you can see what the people complaining about CGI.pm being backwards are really complaining about, and its not header/param, its the no organization , no subroutines/reuse, one shot style ... RAW

For a bare minimum of contrast see cgi101 , sub RootPage, sub RootTemplate , ..., unclunky cgi, ...

Contrast increases only a little bit with with CGI::Application .... If you're using CGI.pm and following CGI to mod_perl Porting. mod_perl Coding guidelines you're 98% modern , only 2% away from using any "modern frameworks" which have a response object

[reply]