On 11/16/05, Ivo van der Wijk <[EMAIL PROTECTED]> wrote:
>
> 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?)
Where would you like to override it? in the method itself? you can
pass tg_template=.. to the returning dict to override the one in
expose()
> 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
>
--
cheers
elvelind grandin
