I spent a couple of hours last night trying to "respectablize" some old Perl scripts.

I have learned much at the feet of my fellow PerlMonks, and now feel rather embarassed at: scripts which can't be run under strict; clunky HTML solutions; non-module form parsing routines and so on.

So last night I went over a script which was a mishmash of HERE documents and print statements and reformed it using CGI.pm.

It really did take a couple of hours, even for a simple script, because I was unfamiliar with the module. Apart from anything else, it seems inconsistent. I can pretty much make any HTML tag I want by just using it (BLOCKQUOTE isn't mentioned in the documentation, but can simply be used like all other tags), but form fields have names that don't relate directly to their HTML names at all, like "textfield".

Anyway, I went through the rather monkish procedure of editing code that already works just fine and removing from it any non-CGI code for rendering HTML/dealing with parameters. Mostly I was just wanting to use the "stickiness" of form fields, because I wanted a form which would re-display with values intact if one of them was missing.

So what does that leave me with:

• A really complex data structure -- just for a form laid out in a table, I've got a AoHoAoA kind of thing six or seven levels deep. I can almost hear PerlTidy sighing when I ask it to lay it out for me.
• I've got ugly-ass code -- even with CGI::Pretty. All tags are in uppercase. Not all tags are indented or lines broken up.
• I've got oldfashioned code, or at least I can't figure out how to make CGI give me HTML 4.0 strict code. I'm guessing the version on my hosting company is a bit out of date because the latest one on my HD Perl installation gives me XHTML unless I over-ride it.
• I've got code about the same length as the HTML would have been if I'd written it myself.

  tag({attribute=>"value"})
  [download]

  isn't any different to <tag attribute="value"> in size after all.
• I've got the stickiness I wanted, without having to come up with my own cludgy solutions, but I notice that when I do my end_form, CGI.pm is adding it's own hidden values to my form anyway in order to achieve the stickiness.
• I've got stickiness I didn't want -- because one of my parameters has the same name as one of my form fields, it was overriding the value, and I had to search the documentation to find out how to force it to accept a value. Simply putting a different value doesn't work. You have to say that that value isn't the value but the "default", and you have to put override=>1 to force it.
• I've got that large complex data structure partly because, I now discover, CGI.pm doesn't like me to print the start of my table, print the rows and print the end of my table. It doesn't have an end_table call unless I specifically request one in the "use" line. So it's "easier" for me to nest every one of my rows, with their nested tds, inside the table's brackets. If I don't do that, I could just write my own custom HTML, like print $q->'</table>' -- but that's just insane. I'm using CGI.pm so I don't have to write my oen HTML any more.

I'm not saying I hate CGI.pm, but I'm a bit disillusioned. Am I missing something? What have I gained for my two hours? Do I just need another coffee? And how can I get CGI.pm to produce valid HTML 4.01 Strict or XHTML 1.0 or whatever in future?
--

“Every bit of code is either naturally related to the problem at hand, or else it's an accidental side effect of the fact that you happened to solve the problem using a digital computer.”
M-J D