CGI.pm and its quirks

I’m a huge fan of the workhorse CGI Perl mod­ule (and pro­gram­matic approaches to markup in gen­eral). Why bother your­self about ret­ro­fit­ting your present­a­tion tem­plates when new doc­types become avail­able — let the module/package/framework/whatever main­tainer handle it for you. CGI.pm has an illus­tri­ous his­tory of sim­pli­fy­ing the hand­ling of input and out­put of HTTP data. There are numer­ous great recipes for build­ing and pro­cessing data flows, from the simple to the com­plex (the per­l­doc is very good too). Where CGI.pm can be some­what annoy­ing is in the some­what select­ively scant doc­u­ment­a­tion regard­ing cer­tain HTML tags — in this case for inline script­ing and styl­ing. So, take note of this par­tic­u­lar caveat. Whenever a HTML tag is added, with only para­met­ers passed and no actual con­tent, like a script tag to your markup that only ref­er­ences an external source file (so dis­tant from the Uto­pianper­l­doc vis­ion of func­tions and calls being sep­ar­ated 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 snip­pet 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 out­put: <script src="/path/to/script/file" />. Once the empty string is in there, how­ever, things work as expec­ted: <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.