CGI.pm and its quirks

I’m a huge fan of the workhorse CGI Perl module (and programmatic approaches to markup in general). Why bother yourself about retrofitting your presentation templates when new doctypes become available — let the module/package/framework/whatever maintainer handle it for you. CGI.pm has an illustrious history of simplifying the handling of input and output of HTTP data. There are numerous great recipes for building and processing data flows, from the simple to the complex (the perldoc is very good too). Where CGI.pm can be somewhat annoying is in the somewhat selectively scant documentation regarding certain HTML tags — in this case for inline scripting and styling. So, take note of this particular caveat. Whenever a HTML tag is added, with only parameters passed and no actual content, like a script tag to your markup that only references an external source file (so distant from the Utopianperldoc vision of functions and calls being separated by head and body tags), make sure that you have an empty string in the block for CGI.pm to taste. Self closed tags other than img and friends? Browser don’t play dat. Here’s a snippet of what I referred to: 
#!/usr/bin/env perl use strict; use warnings; use CGI; my $o = new CGI; print $o->script({-src=>'/path/to/script/file'},'');
Without that empty set of quotes, CGI.pm gives you this output: <script src="/path/to/script/file" />. Once the empty string is in there, however, things work as expected: <script src="/path/to/script/file"></script>.

Sasha

Hello. I’m Sasha Ger­rand, a soft­ware developer. I design and cre­ate high volume trans­ac­tional tech­no­logy (along with other things). I write code in Open Source pro­gram­ming lan­guages. I do things with data sources and trans­ac­tional sys­tems. I use vir­tu­al­ised machines for my server envir­on­ments. I spend a fair pro­por­tion of my days liv­ing in the shell. I like POSIX com­pli­ant oper­at­ing sys­tems and FOSS products.