I've been happy using py:def to define a bunch of slots and utility
macros in a base class, which my other templates inherit, and then using
the normal oo programming technique of defining methods for subclassers
to override to customize the slots of the generic templates. The base
template can call a bunch of hooks that are defined as empty stubs in
the base class, which subclassers of the base template can override to
define specific features.
It hurts my brain less, to just make up some standard callbacks and
naming conventions for slots, and use straightforward imperative object
oriented programming techniques, than to try and emulate the bizarre way
that METAL macros work.
One of the worst problems with Zope and METAL is the way acquisition
goes searching all over tarnation for names. It makes the whole system
unnecessarily slow and impossible to predict and debug -- not a good
trade-off. The false sense of convenience you get from mashing
everything up into the same namespace is vastly outweighed by the
negative consequences, unexpected side-effects and unintended
ambiguities.
As if acquisition wasn't bad enough, the abuse of dynamic scoping (as
well as gratuitous use of REQUEST.set) to pass undocumented parameters
to METAL macros is not only totally insane, but also an essential,
commonly used technique in Plone's METAL templates.
While Kid supports normal Python calling conventions, function
parameters, scoping rules, oo inheritance, etc, thank you. Plus it makes
slick efficient use of generators, which is wicked cool! And you can
always look at the generated Python to figure out what's really going on
and learn how it works behind the scenes.
I try to keep templates as simple and declarative as possible, so it's
easy to understand and modify them without your head exploding, unlike
Plone METAL templates. I like object oriented programming, and I like
Python, and I don't want to forsake both of those niceties just to use a
template system that doesn't provide me with something better. Why
bother using a template system written in oo Python, if the unproven
abstractions it's providing are less powerful and more confusing than
the trustworthy abstractions it's covering up? That's a step backwards!
That's why Kid's so much better and more Pythonic than TAL -- it
synergistically adds power to Python, instead of trying to water it down
(crippled "restricted python") or replace it with something worse (TALES
expressions and all those other silly micro-languages, each with their
own quirks and ad-hoc quoting conventions, and glorious new object
models from outer space).
But I rant...
-Don
