http://qs321.pair.com?node_id=749592


in reply to From PHP to Perl - Should I, and how?

Hello salazar

Have there been any problems or gotchas you have experienced or noticed which consistently occur amongst converts?

Only one thing.

If you are used to the PHP way, you may get an almost 1:1 transition in Web projects using HTML::Mason.

Mason allows you (doesn't force you) to intersperse your HTML with stuff like

[some.html] ... <table class="someclass"> % my $counter = 1; % foreach my $pr (@projects) { % my $rowcolor = ++$counter & 1 ? $color{DARK} : $color{LIGHT}; <tr class="tablefont" bgcolor="<% $bgcol %>"> <td> <% $pr->{topic} %>:</td> <td> <% $pr->{link} %> </td> </tr> % } </table> ...

which is almost a PHP idiom (in contrast to the "smarty" way ;-)

And, you may implement catalyst-like controller logic right into the directory it belongs to (dhandler)

Regards

mwa

Replies are listed 'Best First'.
Re^2: From PHP to Perl - Should I, and how?
by salazar (Scribe) on Mar 10, 2009 at 13:30 UTC
    Sounds cool, and definitely something which will ease my transition, thanks.

    So... what are the differences between using, say CGI::Application and HTML::Mason? I'm guessing it has to do with code separation?
      what are the differences between using, say CGI::Application and HTML::Mason? I'm guessing it has to do with code separation?

      I didn't do CGI::Application so far (should I give it a try?) - but envision it as a all-or-nothing solution for a given web project - whereas Mason is conceptually a lightweight thing close to PHP or JSP and can even be used as an additional templating system for big ships like Catalyst sites.

      see: Comparison

      Another thing: I use both, PHP and Perl (and several other tools too) - and I think PHP *is* an appropriate solution for most small Web projects where the client is hosted on a cheap server (running *only* PHP, of course). Another Comparison (register w/fantasy name to download ;-).

      Regards

      mwa

        No one here will too-seriously argue with you, to be sure... yes, PHP is an appropriate solution for “a helluva lot of projects, big and small, whose success speaks for themselves.”

        It's just that ... well ... ;-) ... none of us would ever want to (again... yuck!) work on such a project!   ;-) ;-)
        ... (unless someone had green money in their hands... then, we'll talk)

        “The elegant beauty of Perl,” in such situations, is:   TMTOWTDI. You've now stumbled-upon at least three of the many contenders that are all “bringin’ home the bacon” every nanosecond in the Internet world. What we hope that you have noticed by now is:   they're all different, yet they're all Perl.

        • Wanna do it “the PHP way?” Cool! Still Perl!
        • Wanna do it “another way?” Cool! Still Perl!

        You are absolutely correct that PHP is “an engineering-wise valid choice” for thousands of web-deployments. The software engineers who designed it and built it are top-notch, and their choices were unquestionably valid for what they intended to do. There is a demand for what they set out to do, and “they did a helluva job.” Every engineering project is a product of its appointed design parameters, at the instant in internet-time when those choices were made, and thereafter it should be judged by nothing else.

        “Know PHP?” You'd be a fool not to.

        “Know Perl?” You'd be unworthy to set foot upon this planet   ;-)   not to.