Rob Nagler wrote:
> The way I understand how plugins work is that they are arbitrary
> classes. But how do you share behavior?
I probably wouldn't use a plugin for something that needed to output
HTML, because that would prevent the designers from editing it. A macro
(basically a mini-template) could be broken down into smaller shared
templates, but there is a practical limit to that approach.
> FILTER does not shared behavior, but is a pipe mechanism.
Yes. I think it would be a good way to do the FONT trick you mentioned
though.
> There is no protocol for communicating between these various
> components except well-known global variables.
That's correct. A template can call macros which are parameterized
(e.g. a macro for making large text headlines which accepts the text as
a parameter), but that's not exactly the same thing. If you find that
you really need to have stateful widgets that share data beyond whatever
model data was passed to the view, then templating is probably not an
appropriate solution.
> For example,
> if a Link is not executable by the current user, it won't render as a
> link (and possibly be completely blank depending on the circumstance
> and configuration).
That's easy to do, but not easy to share between multiple templates with
different appearances.
> Another concern I have about Template Toolkit (and other template
> languages) is that it has its own syntax and semantics for data and
> control structures distinct from Perl. Why isn't Perl good enough?
The syntax for accessing complex data structures in perl is non-trivial
and possibly too confusing for designers.
Here's the perl version:
foreach my $account ( @{$model_data->{'user'}->{'accounts'}} ) {
and in TT:
[% FOREACH account = user.accounts %]
or with localized loop variables, like HTML::Template:
[% FOREACH user.accounts %]
> My experience with "little languages" is that they take on a life of
> their own
That can happen, and I've seen some people do appalling things with
templating tools, but these people tend to be programmers working by
themselves with no separate designer. The place where these tools
really pay off is when you're working with a separate design group. My
experience has been that designers have no trouble grasping the basic
ideas of templating, and don't feel the need to try and wedge in stuff
that doesn't belong there.
The thing that worries me about a widget approach is that I would have
the same problem I had with CGI.pm's HTML widgets way back: the
designers can't change the HTML easilly. Getting perl developers out of
the HTML business is my main reason for using templating.
- Perrin
