[Zope3-dev] Re: Page templates and macro extension

[Fred Drake]

On 8/18/05, Shane Hathaway <shane at hathawaymix.org> wrote:
> My use case for macro extension is as follows: a third party provides a
> complex macro I'd like to reuse as a macro, but I want to replace only
> certain slots in my macro.  I need my macro to offer all of the slots
> that the base macro offers, with only a few exceptions.

That remains the case with the proposed change.

> So for this case, I want an inheritance relationship.

We certainly weren't thinking of it as inheritance.  In fact, that
makes it impossible to support one particular use case (item 3 in our
list below).

> In Zope 2, it's not possible to set up this type of macro inheritance
> relationship.  In order for an intermediate macro to offer slots
> provided by the base, the intermediate macro has to override and
> re-offer each of the slots.  That's a burden when the list of slots
> provided by the base is changing regularly.

Agreed.

> Macro extension is intended to be analogous to subclassing.  In a
> subclass, if you define a method with the same name that a base class
> provides, your method overrides rather than extends the method in the
> base class.

If the subclassing relationship is the right model, yes.  We disagree
that this is the right model.

> Entry #1 of bug #440 demonstrates an inappropriate use of the new
> facility, since the intent of the developer is easily met by existing
> syntax.

The examples are reduced to only show the bug; there certainly may be
additional slots defined in the extended macro, which sounds like your
use case.

> However, bug 440 also demonstrates that the syntax is too
> subtle, and perhaps we need a syntax that explains itself better.

Perhaps the define-macro/use-macro combination should be replaced with
something like define-macro/extends-macro (and the former once more
disallowed), and keep the change from the proposed patch.

Let's make sure we've got the bases covered with this:

1. Slots from the "base" macro can still be filled by the template
containing the use-macro.

2. Slots from the "base" macro can be given a new "default filling"
using this in the "derived" macro:

    <metal:block fill-slot="A">
      <metal:block define-slot="A">
        derived default filling
      </metal:block>
    </metal:block>

This would only be needed for slots that the derived macro wants to
affect; it's not necessary for slots that should be "inherited".

3. Slots can be filled and not made available to the template
containing the use-macro directive by simply not re-offering them:

    <metal:block fill-slot="A">
      final filling
    </metal:block>

Option 3 isn't possible without the changes we've proposed.

  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation