Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: Embeding Perl in HTML the PHP way

by sundialsvc4 (Abbot)
on Sep 11, 2012 at 19:46 UTC ( #993047=note: print w/ replies, xml ) Need Help??


in reply to Embeding Perl in HTML the PHP way

However ...

Generally speaking, Perl does not pursue this objective in (what you call) “the PHP way,” and in my experience:   these days, neither does PHP(!).

The Perl language clearly espouses the notion of “separation of concerns,” where the logic of the application is studiously separated from the presentation.   Typically, a Perl-driven (and a modern-day PHP-driven ...) web-site is viewed as being:   “a program that takes a URL-string and possibly POST-data as input, and which generates an HTML string as output ... using a template to do so.”

If you are still “embedding programming_language into HTML,” then I cordially advise you that you should re-consider that approach.   Even though the PHP language started-out in this direction, it has since shifted away from it ... and, so should you.

P.S.:   I speak as someone equally conversant and up-to-speed in both language systems, not-to-mention many others.   “This is not my first rodeo.”   (As, as you will find, is the case for most of us around here.)


Comment on Re: Embeding Perl in HTML the PHP way
Re^2: Embeding Perl in HTML the PHP way
by heatblazer (Scribe) on Sep 11, 2012 at 19:51 UTC

    I`ll most certainly reconsider what you`ve said. Thanks.

Re^2: Embeding Perl in HTML the PHP way
by davido (Archbishop) on Sep 11, 2012 at 19:58 UTC

    Separation of concerns (the Model, View, Controller) approach is, of course, the primary goal of all of the modern frameworks (including Catalyst, Dancer, and Mojolicious, as well as those popular in other languages). And I agree that the notion of embedding the bulk of an application in the HTML (ie, in the template) is the wrong way to go. But I think you're taking it a little far when you say:

    If you are still "embedding programming_language into HTML," then I cordially advise you that you should re-consider that approach.

    Surely you must mean that the application's business logic should reside in "model" code, the web application's minimal wiring should exist in "controller" code, and the view should reside in the templates, wherein embedded logic is kept to the minimum required, no more, and no less (which is different from reconsidering the concept of embedding altogether).

    Maybe it would help me to understand the line you're drawing if it were accompanied with an example.


    Dave

      Sure, Dave.   What I am referring to is the original concept that a PHP file would consist of HTML code with <?..php code here..?> tags stuck all through it.   For instance, if you wanted to generate an HTML table, you literally enclosed the <tr> tags and so-forth inside of an inline PHP loop.   The idea was that the output would consist of the un-bracketed (HTML) content interspersed with the output that may be produced by any PHP code wherever it appeared.   There was (by design, actually), no separation between the two.

      That turned out to be a really bad idea, and the PHP community quickly moved away from it to adopt MVC strategies that are in many ways quite similar to what one now sees being done in Perl, et al.   The language itself also sprouted many new features, including many similarities to Perl and an openly-acknowledged copy of its regex technology.   I guess good word spreads fast... ;-)   Plus, the Zend folks include some really crackerjack coders.   PHP now does MVC along with the best of them, but the language emphatically didn’t start out that way.   (But hey, it sure seemed like a perfectly good idea at the time ...)

        I think you're being awfully generous in suggesting that "the PHP community" has moved away from the everything-in-one-file method. Outside of some big projects like Drupal and work being done by some elite coders, I think most PHP scripts still mash it all together. From what I see, although there are still plenty of CGI/HTML scripts out there, Perl is way ahead in that regard.

        That ability to toss a little code into an HTML file is what made PHP popular, after all. You didn't have to deal with file permissions or any of the stuff that made CGIs tricky at times; just stick your code in the page. That method makes large projects nearly impossible -- systems like Drupal and Wordpress are a mess, even with separation of code and layout -- but it makes the quick-and-dirty stuff quick. Take that away, and you're left with what, about a thousand inconsistently named functions?

        Aaron B.
        Available for small or large Perl jobs; see my home node.

Re^2: Embeding Perl in HTML the PHP way
by GrandFather (Cardinal) on Sep 12, 2012 at 10:32 UTC
    these days, neither does PHP(!)

    I really wish that were true, but it isn't, at least in my limited experience. The worst offenders seem to be some of the big guns like Drupal and Joomla (I've not looked at WordPress in sufficient detail to know)!

    Those systems positively encourage template files that are a sea of PHP immersed in an ocean of HTML with the result that you can generally find neither the forest nor the trees.

    Having worked with PHP extensively over the last few months I can confirm all the rumours that suggest PHP took only those parts of Perl the author understood (not very much actually), reimplemented badly those bits that weren't understood, provided multiple inconsistent implementations where there were several alternatives, and then added functions for anything anyone ever asked for. The result is not good!

    True laziness is hard work

      That's the templates though. Intermingled code and HTML are par for the course when it comes to templates. (TT2 does this just as much. Example from the documentation. It's not Perl code intermingled - it's worse; its a whole other Turing-complete language.) The files that the browsers actually hit start with <?php and don't contain a ?>, so they're PHP all the way; not HTML with little chunks of PHP.

      There are plenty of awful things about the design of Drupal. This is not one of them though.

      Update: in case anyone doubts the Turing completeness of TT2...

      use Template; my $template = Template->new({ POST_CHOMP => 1, EVAL_PERL => 0, # note: false! }); $template->process(\*DATA, {}, \*STDOUT) or die $template->error; __DATA__ [% MACRO fib(n) BLOCK %] [% IF (n < 2) %] [% n %] [% ELSE %] [% fib(n - 1) + fib(n - 2) %] [% END %] [% END %] Fibonacci sequence... [% FOREACH i IN [ 1 2 3 4 5 6 7 8 9 10 ] %] [% fib(i) +%] [% END %]
      perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://993047]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2014-12-25 20:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (163 votes), past polls