Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Web Application Frameworks and their Templating Engines with a Comparative Study of Template and HTML::Template

by princepawn (Parson)
on Apr 26, 2001 at 02:16 UTC ( #75645=perlmeditation: print w/ replies, xml ) Need Help??

Data, Logic, Display: The Multi-Tiered Decoupled Approach to Web Design

In Refining the CGI process through structure and templates, boo_radley does state:
A good CGI framework should provide 1.Template handling -- go TT2! Keeping templates divorced from code allows me to to farm out HTML and probably SQL, not to mention benefits of maintenance, etc
But one must ask. Does Template force one to separate Perl and HTML? The answer is no, it does not. In fact, anything you can do in Perl, you can do using the [% PERL %] Template directive.

Furthermore, Template exports a mini-language, containing loops and conditionals and simplified methods of defining Perl hash and array refs. And beyond that, people have written plugins to extend this mini-langauge even further to support database interaction among other things.

So, with Template as your templating solution, you have Perl and Template as programming languages and then you have HTML.

On the other hand HTML::Template has far more limited mini-language, forcing one to do much more in pure Perl.

Web App Frameworks and Their Chosen Template Engine

OpenInteract made by our own lachoy. Template
boo_radley's framework Template
CGI::Application HTML::Template
CGI HTML::Template --- this is not entirely true. What is true is that HTML::Template @ISA qw(CGI) And therefore anywhere that you use HTML::Template you are already using CGI.
Apache::PageKit HTML::Template
AxKit XPathScript or XSLT (your choice)
CGI::MxScreen None --- use what you want
HTML::EP Builtin --- has a Perl tag (uh-oh). Is extensible (uh-oh#2).
BingoX Builtin --- has a Perl tag (uh-oh). Is extensible (uh-oh#2).
CGI::Portable It's can't figure out what it has.
LibWeb I can't figure out what it has!
HTML::Embperl and HTML::Mason Perl. That may sound funny but that's how these two modules do it. Of course you can develop your own HTML display modules in Perl and use them inline.

Conclusion

In my eyes, Template is offering replicated functionality through its too-powerful and too-feature-packed mini-language. There is nothing that this mini-language offers that cannot and should not be done in re-usable Perl modules.

On the other hand, HTML::Template by creating a very narrow snake's tube between Perl computation and HTML display, forces one to use Perl for it's strength and HTML for it's without any chance for the feature overlap phenomenon that has happened with Template.

Comment on Web Application Frameworks and their Templating Engines with a Comparative Study of Template and HTML::Template
Select or Download Code
Re: Web Application Frameworks and their Templating Engines with a Comparative Study of Template and HTML::Template
by BMaximus (Chaplain) on Apr 26, 2001 at 03:33 UTC
    I've been using HTML::Template for almost two years now. I agree with princepawn that it does separate Perl from HTML for the most part. One thing that I can't stand is seeing HTML bloating code like an overfed pig. Sam Tregar, its writer has done a fantasic job of making a feature rich module making it easier for webmasters to do their job without realy having to bang their head against the wall trying to decipher what the code is and does. One of the main reasons I like HTML::Template so much is that it goes very well with mod_perl. Its ability to cache templates is invaluable. Creating and using tags from it is simple, yet you can make very complex pages out of it. The person who is marking up the pages, all he/she has to do is understand the tags defined by the programmer and how to arrange them.

    BMaximus
Re: Web Application Frameworks and their Templating Engines with a Comparative Study of Template and HTML::Template
by merlyn (Sage) on Apr 26, 2001 at 03:44 UTC
    In Template, Perl sections are controllable with a config param. So you can force all Perl code to be outside of template files. UhOh #1 goes away.

    And by giving a nice mini-language, presentation logic can be encoded in the template, while data logic is traditionally coded in the Perl side, and carefully controlled. Yes, people blur it in both directions, but that's a style issue, not inherent in the design.

    And to the comment that HTML::Template is cached under mod_perl, well, so is Template. {grin}

    -- Randal L. Schwartz, Perl hacker

Re: Web Application Frameworks and their Templating Engines with a Comparative Study of Template and HTML::Template
by Masem (Monsignor) on Apr 27, 2001 at 01:29 UTC
    One of the addition benefits of Template (beyond what merlyn said), is that Template is language neutral, and as WAP-enabled sites become more common, using Template over HTML::Template may become beneficial, since all you need to do for delieving WAP vs HTML is change the template file; you should not have to touch any perl code save to point the Template processor to the right place. And then adding text-only becomes simplier as well.

    But regardless of the templater that you use, spliting perl code from HTML is one of the most benifical thing you can do with for your CGI.


    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
      One of the addition benefits of Template (beyond what merlyn said),
      There is nothing that merlyn listed in his post that shows an advantage of Template over HTML::Template. He did place it on equal ground but did not state any features it held that HTML::Template did not.
      is that Template is language neutral, and as WAP-enabled sites become more common, using Template over HTML::Template may become beneficial, since all you need to do for delieving WAP vs HTML is change the template file; you should not have to touch any perl code save to point the Template processor to the right place. And then adding text-only becomes simplier as well.
      Your point about easily changing the display method from HTML to something else is well-taken as an advantage of Template It was a key point in davorg's article which I found on his website and which seems to have vaporized from perl.com However, consider this part of your statement:
      you should not have to touch any perl code save to point the Template processor to the right place.

      But the obvious question is: you will have to change the display code, right? How would one change all the HTML tags to the formatting conventions of another format? Ie, plain text, XML, HTML, or WAP? One way would be to code in "Template HTML" so that you could transform all the tags at once, ie:

      [% H1 %] This is a header [% OL %] [% LI %] we can make an HTML file if we want, [% LI %] but we could make some thing else [% LI %] just as easy. [% OL %]

      This is just brainstorming. I don't have a full answer.

        Well, that's the important part with regards to having one perl script put out output for numerous output formats. If the "output generation" is sufficient separated from the perl code, the perl code and logic is much clean, and all that is left to do is to write, for each output type you want to support, a template to fill in the blanks. If you set up the arguments that you pass to Template correctly, for example, you don't need to change the data that you pass to the Template processor, and in the various files, you write what you want to include. For example, if I was writing a on line bookstore, the HTML front end might have not only the ISBN, price, publisher, etc, but the short synapsis, reviews, etc etc. on every page. On the other hand, I might only want the ISBN, and short details for a WAP output. But I only need to write one database call to do both.


        Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
        davorg's article which I found on his website and which seems to have vaporized from perl.com.

        It is still on perl.com, it's just a little tricky to find. It's here.

        Another advantage of TT2 that you seem to have missed, is that TT2 isn't tied to web applications. It can be just as easily used in any kind of data processing system. I know people, for example, who use it to generate DNS zone files. How easy is that with HTML::Template?

        --
        <http://www.dave.org.uk>

        "Perl makes the fun jobs fun
        and the boring jobs bearable" - me

Re: Web Application Frameworks and their Templating Engines with a Comparative Study of Template and HTML::Template
by markjugg (Curate) on Jun 03, 2001 at 19:20 UTC
    My two cents: I've used HTML::Template for a number of applications and I'm very happy with it. I use it for generating email messages as well as HTML pages. I've found it's strict seperation of code and design a very useful metaphor. I feel like this clean seperation of code and design helps speed up my development time as my brain seems to do better to focus on one or the other than to intertwine them.

    -mark

Re: Web Application Frameworks and their Templating Engines with a Comparative Study of Template and HTML::Template
by pmas (Hermit) on Jul 06, 2001 at 19:23 UTC
    Thank you, monks, for excellent article and real-life insight.

    I propose to add link to this meditation from Module Review part of monastery - and I am wondering how many other excellent comparisions of other modules I missed.

    So much more to learn...

    pmas

    To make errors is human. But to make million errors per second, you need a computer.

Re: Web Application Frameworks and their Templating Engines with a Comparative Study of Template and HTML::Template
by perrin (Chancellor) on Aug 15, 2001 at 07:02 UTC
      Now that is a nice fuckin article. Excuse my language. But you went balls out on that one. I'm surprised that with your background at eToys that you didn't mention BingoX::Chromium and XPP.

      Your article would go well with the new book c_monster announced at use.perl.org entitled "Perl for the Web" which I think is also excellent.

        Thanks. I actually did mention XPP, but it's really not as good a choice as the other modules I reviewed so I only covered it very briefly. BingoX::* was not something we used at eToys. It was used (and developed) by another company who we contracted to build a children's entertainment section of the site, which was totally independent and ran on separate hardware. eToys used a couple of homegrown templating systems, and later switched to Template Toolkit.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2014-07-26 05:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (175 votes), past polls