| [reply] |
It has been requested. Perhaps one of the modern frameworks already caters for this. CGI.pm is starting to really show it's age.
| [reply] |
Generating a web page with CGI is kinda like assembling a bookshelf by gluing chopsticks together. Yes, you get there, but you spend too much effort dealing with tiny details.
Take a look at Catalyst, Dancer, Mojolicious, which greatly simplify the process of generating a set of pages for a website, including templating, common elements, authorization, and so on.
As Occam said: Entia non sunt multiplicanda praeter necessitatem.
| [reply] |
| [reply] |
| [reply] |
| [reply] |
| [reply] |
The CGI module is exactly what it promises to be – which is to say, “not much.” It literally consists only of “sugar” for the various elements of the HTTP protocol ... in the context of a vanilla-CGI script. And yet, it is currently maintained, and everything that is said about it in the DESCRIPTION section of the CPAN page is still true:
CGI.pm is a stable, complete and mature solution for processing and preparing HTTP requests and responses. Major features including processing form submissions, file uploads, reading and writing cookies, query string generation and manipulation, and processing and preparing HTTP headers. Some HTML generation utilities are included as well.
CGI.pm performs very well in in a vanilla CGI.pm environment and also comes with built-in support for mod_perl and mod_perl2 as well as FastCGI.
It has the benefit of having developed and refined over 10 years with input from dozens of contributors and being deployed on thousands of websites. CGI.pm has been included in the Perl distribution since Perl 5.4, and has become a de-facto standard.
As you feared, if you want a DOCTYPE or anything-else in the HTML header, or anywhere else, you have to do it yourself. You will need to use a debugger on the client side (e.g. Firebug) to actually examine precisely what the HTML returned is. (Or, you can use curl.)
It definitely would be worth your time to explore other options, like the CGI::Application family ... which, no surprise here really, uses CGI to do its heavy lifting, yet provides both a structured framework for “the whole enchilada” and introduces the concept of plugins, providing for a very helpful “separation of concerns.” I suggest it because it is a relatively modest step from your present-state, yet offers excellent performance.
| |