Perrin Harkins writes: > I just didn't put in any fancy HTML in my example. I could have put in > table tags right there, or made a macro if that table gets repeated a > lot. Looks to me like they work the same. In TT, I would probably use > macros or small templates (possibly defined in this same template file > at the top) for little repeating chunks, and filters or plugins for > things with more brains, like the String widget that decides whether or > not it needs to print FONT tags.
The way I understand how plugins work is that they are arbitrary classes. But how do you share behavior? I couldn't find any protocol for sharing behavior in Template Toolkit. FILTER does not shared behavior, but is a pipe mechanism. PLUGIN can only communicate through $context (global variables). WRAPPER is another form of FILTER. INCLUDE, PROCESS, MACRO, and BLOCK are simple textual substitution. PERL is the same as a inline PLUGIN. There is no protocol for communicating between these various components except well-known global variables. Yes, you could invent a protocol, but it wouldn't be compatible with somebody else's protocol. Widgets can inherit behavior from other widgets. For example, the Enum widget is a subclass of String. Enum overrides the render() method, because it provides interesting behavior on enumerated types in certain cases. If the interesting behavior is not applicable, it defers to String by calling $self->SUPER::render(@_). We use inheritance quite a bit. For example, CheckboxGrid and RadioGrid inherit from Grid. We have a ControlBase widget which supplies the structure for boolean-controlled widgets. 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). 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 bOP view language implementation is about 100 lines of Perl (no XS), and gives you all the power of Perl. The Widget interface contains three methods (new, initialize, and render), which provides extensibility through Perl classes. Variables are provided through the WidgetValueSource which has two methods. Finally, for "macros" there are ViewShortcuts which are Perl subroutines collected in a class (which usually inherits from other classes). All of this is plain old Perl. My experience with "little languages" is that they take on a life of their own, viz. Apache's configuration language and mod_rewrite. They become more and more complex until they become yet another programming language. This is what Template Toolkit has become imo, and so the argument about template languages being "easier than Perl" is specious. Rather, they become harder, because you have to think in two languages instead of one. Just my $.02 or so... :-) Rob
