[ZPT] [Weakness] "metal:fill-slot" and "metal:use-macro" not together

[Dieter Maurer]

Evan Simpson writes:
 > ....
 > It is my intention that METAL will work like this:
 > 
 > During parsing:
 > ....
 > 2. 'fill-slot' is only valid in a 'use-macro', and 'define-slot' is only 
 > valid in a 'define-macro'.
Please consider nested macro definitions.

  I used several times the following scenario:

    Inside a macro, I define another macro, for example
    to be used inside the first macro.

    Example: outer "Display" macro; inner "Navigation" macro;
      "Navigation" defined in "Display" and used to
      provide navigation at both page top and bottom.

As soon as we have nested macro definitions, the
reference of a "define-slot" is no longer obvious.

It seems that the current implementation associates the
"define-slot" with all enclosing macro definitions,
which is quite good.

But the semantics should be clearly stated....


 > 3. Inside a 'use-macro', all METAL statements other than 'fill-slot' are 
 > ignored.
But the 'fill-slot' content itself should not be seen as part of the
'use-macro' as it does not belong to the macro but to the
calling context.

I regularly define macros inside 'fill-slot' elements.....

 > ....
 > During source macro expansion:
 > 
 > 1. METAL statements in the page are left unchanged.  METAL statements in 
 > expanded macros are stripped out.
 > 
 > This means that if you use a macro that has embedded macro definitions, 
 > or that uses other macros itself, none of that METAL markup will appear 
 > in the expanded macro text.
I feel this will be  correct behavior. However, I need to think
more about it....

Again: metal statements from "fill-slot" should not be changed or stripped...

  Once, I wanted to use "define-slot" for the same name several times
  in the same macro to ensure that the same information is inserted
  at all these places. I did not tried it because I felt it might
  make problems and the given situation called for slight modifications
  anyway. 

  Consistent use of some information may be a considerably use case
  (that one of the reasons, we have variables...).
  We may find better approaches than multiple definitions of
  "define-slot" with the same name.

  When we would go for multiple definitions, then maintaining
  the metal statements inside the "fill-slot" would make
  problems.


Dieter