CGI.pm and HTML5

space_monk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: CGI.pm and HTML5 by karlgoethebier (Abbot) on May 03, 2013 at 16:37 UTC
Take a look at How do I get CGI.pm to output HTML5 instead of XHTML 1.0?. Regards, Karl «The Crux of the Biscuit is the Apostrophe»	[reply]
Re^2: CGI.pm and HTML5 by timlank (Initiate) on Sep 30, 2024 at 22:00 UTC
Also: How do I get CGI.pm to output HTML5 instead of XHTML 1.X?	[reply]
Re^3: CGI.pm and HTML5 by karlgoethebier (Abbot) on Oct 01, 2024 at 14:03 UTC
He! 11 (!) long years later. «The Crux of the Biscuit is the Apostrophe»	[reply]
Re: CGI.pm and HTML5 by TomDLux (Vicar) on May 03, 2013 at 17:02 UTC
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]
Re^2: CGI.pm and HTML5 by space_monk (Chaplain) on May 03, 2013 at 17:07 UTC
Yes I would love to use more modern modules to do this but I'm a bit constrained by the environment I have to work in. None of those modules are installed. Its a fairly vanilla Perl 5.8.8 installation If you spot any bugs in my solutions, it's because I've deliberately left them in as an exercise for the reader! :-)	[reply]
Re^3: CGI.pm and HTML5 by marto (Cardinal) on May 03, 2013 at 17:13 UTC
I just installed Dancer on an old Solaris system with 5.8.8, no issues.	[reply]
Re^4: CGI.pm and HTML5 by space_monk (Chaplain) on May 04, 2013 at 16:21 UTC
Re^3: CGI.pm and HTML5 by derby (Abbot) on May 04, 2013 at 12:04 UTC
While I can empathize with the need for infrastructure stability, relying on a seven year old release of any 'progressing' product is not good. Maybe you could use this bit of friction to open a dialog with your 'powers that be' about modernizing the toolset? -derby	[reply]
Re^4: CGI.pm and HTML5 by space_monk (Chaplain) on May 04, 2013 at 16:07 UTC
Re: CGI.pm and HTML5 by marto (Cardinal) on May 03, 2013 at 16:37 UTC
It has been requested. Perhaps one of the modern frameworks already caters for this. CGI.pm is really starting to show it's age.	[reply]
Re: CGI.pm and HTML5 by Anonymous Monk on May 03, 2013 at 17:44 UTC
Even CGI::Application is pretty fine. And Template::Toolkit.	[reply]
Re: CGI.pm and HTML5 by locked_user sundialsvc4 (Abbot) on May 04, 2013 at 16:08 UTC
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.