perlmeditation
princepawn
<h2>Data, Logic, Display: The Multi-Tiered Decoupled Approach to Web
Design</h2>
In [Refining the CGI process through structure and templates],
[boo_radley] does state:
<blockquote>
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
</blockquote>
But one must ask. Does [cpan://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
<code>[% PERL %]</code> Template directive.
<P>
Furthermore, [cpan://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.
<P>
So, with [cpan://Template] as your templating solution,
you have Perl and Template as programming languages and then
you have HTML.
<P>
On the other hand [cpan://HTML::Template] has far more
limited mini-language, forcing one to do much more in pure
Perl.
<P>
<h2>Web App Frameworks and Their Chosen Template Engine</h2>
<table border=1>
<tr>
<td>[cpan://OpenInteract]
made by our own [lachoy].
</td>
<td>
[cpan://Template]
</td>
</tr>
<tr>
<td>
[boo_radley]'s framework
</td>
<td>
[cpan://Template]
</td>
</tr>
<tr>
<td>
[cpan://CGI::Application]
</td>
<td>
[cpan://HTML::Template]
</td>
</tr>
<tr>
<td>
[cpan://CGI]
</td>
<td>
[cpan://HTML::Template] --- this is not entirely true. What is true is that
<code>HTML::Template @ISA qw(CGI)</code> And therefore anywhere that you
<code>use HTML::Template</code> you are already using CGI.
</td>
</tr>
<tr>
<td>
[cpan://Apache::PageKit]
</td>
<td>
[cpan://HTML::Template]
</td>
</tr>
<tr>
<td>
[cpan://AxKit]
</td>
<td>
XPathScript or XSLT (your choice)
</td>
</tr>
<tr>
<td>
[cpan://CGI::MxScreen]
</td>
<td>
None --- use what you want
</td>
</tr>
<tr>
<td>
[cpan://HTML::EP]
</td>
<td>
Builtin --- has a Perl tag (uh-oh). Is extensible (uh-oh#2).
</td>
</tr>
<tr>
<td>
[cpan://BingoX]
</td>
<td>
Builtin --- has a Perl tag (uh-oh). Is extensible (uh-oh#2).
</td>
</tr>
<tr>
<td>
[cpan://CGI::Portable]
</td>
<td>
It's can't figure out what it has.
</td>
</tr>
<tr>
<td>
[cpan://LibWeb]
</td>
<td>
I can't figure out what it has!
</td>
</tr>
<tr>
<td>
[cpan://HTML::Embperl] and
[cpan://HTML::Mason]
</td>
<td>
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.
</td>
</tr>
</table>
<h2>Conclusion</h2>
In my eyes, [cpan://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.
<P>
On the other hand, [cpan://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 [cpan://Template].