On 11/16/05, Don Hopkins <[EMAIL PROTECTED]> wrote: > > 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. >
py:def is excellent, and I love the way you can pass arguments to it, and it simply works! This is one of the worse parts about metal, I agree > 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. > Still, I think the macro/slot concept is really good and it has no equivalent in Kid (yet). Again, if I wanted Zope or Plone with all its issues, I'd use Zope or Plone :) > 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. > I never said I wanted acquisition (though Plone uses it for its skinning system). Zope3 for example has no (implicit) acquisition but it has a similar layer/skin system. > 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. > True (though I never used REQUEST.set, that's soooo dtml-ish ;). But you'll need to define your macro arguments through tal:define, yes. > 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). > Again, I don't want TG or Kid to become Zope, Plone or ZPT. What I do miss is: Defining views independend of code. Currently you're supposed to return html from your methods or define which template to use through expose(). This is fixed and there's no way to override the defined template (Right? Or am I missing something?) kid is indeed really pythonic, and I think it's alot clearer than ZPT / Tal. However, it has its limitations, py:def just can't handle my usecases, which include including pieces of templates "from elsewhere" and have parts of that template filled in, i.e. (pseudo code) <div py:usemacro="article_macro"> <div py:slot="header">Breaking news! <b py:content="title">Title</b></div> <div py:slot="intro">A short intro</div> <div py:slot="body">A lengthy body with markup, images and links</div> <!-- leave footer with copyright stmt untouched --> </div> passing title/intro/body as arguments to a pythonmethod would really be messy. Perhaps I Just want too much flexibility, but this is what I currently need for my project, partially because I want to generate a default set of widgets,forms,etc and have people customize only those parts that they want to be different. Regards, Ivo -- Drs. I.R. van der Wijk / m3r Consultancy B.V. Linux/Python/Zope/Plone and Open Source solutions PO-box 51091, 1007 EB Amsterdam, The Netherlands Email: ivo <at> m3r.nl
