* Rafiq Ismail <[EMAIL PROTECTED]> [2002-04-18 05:24]:
> We've got this Mason only guy who is trying to challange our decision
> to rebuild a site in Template, as opposed to Mason. Also that it's
> more usable for designers. We've got to defend this soon.
Each system is good, complete, and robust. HTML::Mason presents itself
much less as a toolkit, and more as an application server/delivery
platform, but in reality it is also a toolkit.
In fact, TT and HTML::Mason are similar in many ways. Both compile down
to disk-cachable Perl (HTML::Mason does this by default, TT on request).
Both allow highly modular, componentized development, and components can
be arbitrary located on the file system (Mason allows for multiple
directories of file-based components, which makes it straightforward for
non-Perl programmers to create components, while TT allows for plugins
that are full Perl modules, and located based on namespace, searched
via Perl's @INC).
* Andy Wardley <[EMAIL PROTECTED]> [2002-04-18 06:01]:
> In Mason you put your Perl code and HTML markup in the same file. In
> TT you are encouraged (but not forcecd) to put your HTML and
> *presentation* logic in templates, and your Perl and *application*
> logic in separate plugins, modules, subroutines or whatever.
This isn't required, though, and you can definitely write Mason components
that are only HTML, with calls to other mason components, and mason
components that are only Perl. It's all in how it's used. For example,
the Mason way:
# index.html
<& /mason/header, title => "Hello World" &>
<h1>Hello, world</h1>
<& /mason/footer &>
# /mason/header
<html>
<head>
<title><% $title %></title>
</head>
<body>
<%ARGS>
title => ""
</%ARGS>
# /mason/footer
</body>
</html>
The TT way:
# index.html
[% INCLUDE "tt/header" title => "Hello, World" %]
<h1>Hello, world</h1>
[% INCLUDE "tt/footer" %]
# tt/header
<html>
<head>
<title>[% $title %]</title>
</head>
<body>
# tt/footer
</body>
</html>
Which is easier? Which is "less" HTML? It depends on how you use them.
You can do ugly perl in the middle things with TT, too, with USE_PERL.
As far as using plugins, HTML::Mason allows you to integrate them
more smoothly, because the syntax is identical:
# TT example: Plugin
packge Template::Plugin::Sendmail;
use base qw(Template::Plugin);
use Mail::Sendmail ();
sub sendmail {
my ($self, $params) = @_;
Mail::Sendmail::sendmail(%{$params});
}
# in the template
[% USE sm = Sendmail %]
[% sm.sendmail(To => "...", From => "...", ...) %]
The mason way:
# sendmail.comp
% use Mail::Sendmail ();
% Mail::Sendmail::sendmail(To => $to, From => $from, ...)
<%ARGS>
$to => "default to"
$from => "default from"
$subject => "default subject"
...
</%ARGS>
# in the template:
<& /mason/sendmail.comp, to => "...", from => "..." &>
Which is easier? Which is "less" HTML? It depends. With HTML::Mason,
because components are all file-based, they are instantly recompiled
when they change, too. Which also means that things break in real time,
but, that never happens to us, right?
Mason tends to be pushed more for coders who also do HTML (or HTML folks
who aren't afraid of Perl) than TT, which pushes separation of logic
and presentation specifically.
* Andy Wardley <[EMAIL PROTECTED]> [2002-04-18 06:01]:
> This makes is much easier to develop, maintain and update application
> and presentation code separately. You can run the same application code
> simultaneously with a dozen different front ends, and you can reuse the
> same presentation templates across a dozen different backend applications.
This is true for any well designed system. Despite the name, there is
very little HTML-specific about HTML::Mason, other than an HTML-ish
syntax. It doesn't even come with HTML shortcut components, like TT
does. There are several aspects to the overall system that are
optimized for httpd-type processed (the autohandler and dhandler stuff,
for example), but these are happy perks that you can get along just
swimmingly without.
* Rafiq Ismail <[EMAIL PROTECTED]> [2002-04-18 05:24]:
> My initial reasons were that template allows us to build a more
> generic system which is not just web-centred.
HTML::Mason does not require that what you emit be HTML, although it
runs questionably outside of a web server context. You can set up
simple handlers for *.html files and *.xml files, which each set the
appropriate content type, set the component root and data directory to
one appropriate for the content type, and then call $ah->handle_request
(I'm refering to the conventions in the HTML::Mason examples).
> I'd appreciate some pointers about session management approaches vs
> Mason custom.
In the Mason docs, there are examples of how to tie Apache::Session into
your Mason application, and even an almost complete handler that you can
use with session stuff in there. But a competent Perl programmer will
be able to look at the examples and instantly be able to deduce what
part is HTML::Mason and what part will apply universally, to whatever
templating system that is chosen. Session support does not exist in
Apache::Template, but if you are writing your own template processor,
you can add it trivially.
As I reread the above, I feel like I ended up defending HTML::Mason to
an implicitly hostile audience, which I hope is not true. HTML::Mason
has a lot of good things to offer, as does TT of course, and I would say
that if there is a substantial reason not to switch (a lot of already
written HTML::Mason stuff you're trying to integrate, like RT, or if
you're developers are already comfortable with HTML::Mason), don't
switch just for the sake of switching; the overall gains of TT will not
make the porting trip bearable. It's easier for a competent developer
to make a small, fast web application using TT than Mason, because TT is
a toolkit, from which you can pick the pieces you need. You can even
process templates offline using tpage, for which there is no (stock) Mason
equivalent.
If you're starting from scratch, though, I feel that TT offers a
cleaner, more developer oriented approach to the separation of logic and
layout, especially in the documentation. TT's documentation assumes you
aspire to MVC bliss, while the HTML::Mason docs are geared towards
people who will be writing at least some HTML, and more generally
towards people who will be writing a *lot* of HTML.
(darren)
--
Your only obligation in any lifetime is to be true to yourself.
Being true to anyone else or anything else is ... impossible.
-- Richard Bach
