in reply to Re^2: image and href tags in CGI.pm
in thread image and href tags in CGI.pm

I wonder what's worse. Some guy writing code the way he wants (using CGI.pm) or some (HTML::)Template( Toolkit) zealot...

Your reaction is nothing but a Pavlovian reaction. Instead of explaining what is wrong with producing CGI.pm HTML in a normal way, you try to make the OP look bad for even talking about CGI.pm. You don't know anything about the project (s)he's working on, so you can't tell wheter using CGI.pm is really a bad choice.

Just because you think(/read that) using CGI.pm for HTML creation is bad, doesn't mean that others can't be happy with it.

Please, please give some more structured criticism instead of this zealotry.

--
b10m

All code is usually tested, but rarely trusted.

Replies are listed 'Best First'.
Re^2: image and href tags in CGI.pm
by BUU (Prior) on Jan 03, 2005 at 23:21 UTC
    Which part of
    Not only do you have the usual flaws of embedding the html(presentation) in your code(control), you don't even make the html in an easily recognizable form.
    Did you not understand? I present two clear criticisms. One is that embedding the html generation in the code is usually a bad idea REGARDLESS OF THE APPLICATION. The second is that the embedded form of the code is extremely ugly when you use CGI.pm. Using CGI.pm to produce html leads to complicated overdone code that is hard to read and understand.

    And yes, templates are good, but I'd much rather see the person just use prints statements to output the html, rather than the horrible functions exported by CGI.pm.

    Update Just a node responding to both replies: Nothing I have said precluded the possibility of keeping the script as one file. Any sane templating system (HTML::Template, just for example) will let you embed the template *in* the same file as your script is, for example below the __DATA__ line, or even just as a giant quoted string.
[reply]
      80% of the CGI interaction out there is "single form, single response" apps. I think your statement doesn't apply there. There's nothing wrong with putting the HTML and the response handler in the same file for that.

      And if you do that, you gain the sticky-fields features of CGI.pm's form creation, and some high level constructs for radio-groups and checkbox-groups.

      I think you're throwing the baby out with the bathwater when you say "don't use CGI.pm's HTML constructs". For 80% of the apps out there, it's just fine. I can agree with you that it doesn't scale, though. And when someone gets to one of those other 20% of the apps, they'll learn Template Toolkit or something.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

[reply]

      One advantage of using something to generate small amounts of HTML is that as specs change, that single module can be upgraded and your site can meet new specs. Like moving from HTML to XHTML. This is not a general reason for using, and personaly I have never used it. However there are cases (like the generation of some Perlmonks HTML) in which it *can* be a good idea that improves the quality of code. To each his own though, sometimes a print statment just fits the bill, but sometimes it doesn't.


      ___________
      Eric Hodges
[reply]

      What makes you think that I don't understand what you're posting? I'm merely pointing out that, even when you disagree, you still can be polite, hence my "explaining what is wrong with producing CGI.pm HTML in a normal way"

      I disagree on the way that embedding HTML generation in the code is always wrong. For simple scripts, it can be damned handy to keep everything in one big file. Although I haven't benchmarked it (and I'm not planning to do so), I believe for some scripts it's way faster not to use templates.

      Besides that, your second point is of course totally ridiculous. So because you think the "embedded form of the code is extremely ugly", the OP shouldn't even think about using it?

      So, yeah, to conclude, I have to give you credit for the "two clear criticisms". Those are totally non-biased arguments. Totally not based on opinion and zealotry. Sorry for that. I stand corrected. It's all very clear to me now.

      --
      b10m

      All code is usually tested, but rarely trusted.
[reply]

In Section Seekers of Perl Wisdom