Ahhh - dunno, we never use that :) We publish to Zope, rather than coding in it - all code is written and stored in cvs offline, loaded up automatically to Zope (our main app has a "refresh pages" link that cvs up's and removes/loads up all the ptl from scratch), and published from there to web. Don't really use the ZMI for much more than the ocassional refresh of a product - everything else is done programmatically. Don't think that should make that much difference, though - if "expand macros" means you can't dynamically include or exclude macros, then it seems like something we wouldn't want to do. The code below works well for what we do, and suggests (as you've pointed out) that the spec may not be entirely clear on whether tal or metal is resolved first under what conditions. KevinL On Sat, 2002-08-24 at 03:15, Dieter Maurer wrote:
KevinL writes:
... I just added a page template, test_macro, and surrounded the default content with "metal:block define-macro="test". I added another ptl, test, and made it consist entirely of:
<span tal:define="mName string:test"> <metal:block use-macro="here/test_macro/macros/?mName"> </metal:block> </span>
When you view test, you get the test_macro macro appearing.
This works. More than that, the conditional picking of macros like that is important, I think - otherwise a lot of the dynamicness of a site vanishes. Perhaps we're talking at cross-purposes? Or have I been relying on a brokenness in macros/tal? I can certainly see in the documentation that it says macros are expanded before tal is executed, but that seems to not be the case in practice? What happens when you turn on "Expand macros when editing"?
Dieter