I suppose it could, if you banged hard enough, but that's not really what slots were made for... are you filling the slots with "live" ZPT snippets, or just HTML? If the latter, you probably want to use tal:content="structure stuff_to_insert".
Well, I think slots are perfect for what I'm doing. :-) I'm creating a content type which composes the views of several objects (the exact objects are picked by the end user) into a single view. Developers can write a page template with a macro called "CompositeListing" and register this template with a tool. Once registered, users can pick the template as a layout for the composite listing page. The view of the composite listing page invokes the CompositeListing macro in the chosen page template. This renders the layout. The idea is that layout template authors puts slots in the layout template where they want content to go. This is used not only for aggregating content, but also for managing the layout - a different page lets the object creator choose from a drop-down which items appear in which list. This is achieved by filling the relevant slots with form elements rather than aggreagted content. So far, I've done it with hard-coded slot names slot0, ..., slot9. It works very well, except for the inconvenience of having to use these pre-defined slot names. I don't want to invert the control, forcing template layout authors to invoke the correct aggreagted content or display macro. It is an important requirement that layout templates are as easy to write as possible. Something like <div tal:define-macro="CompositeListing"> <div tal:define-slot="slot0"/> <hr/> <div tal:define-slot="slot1"/> </div> is all that is required for a simple two-row composite listing. Any additional complexity comes purely from the layout, not from invoking the correct aggregation. How hard would I have to bang? Martin -- "Life is both a major and a minor key" -- Travis, Side