There are a few things I'm trying to understand about the xmlc-like Templates proposal. First : "Using specialized webdesigners with Zope project has been one of the biggest pains in Zope development; we have to take the sometimes ugly code generated by the tools they use, usually clean it up, then insert the DTML tags in it. Making changes to the design is a nightmare." http://lists.zope.org/pipermail/zope-dev/2000-September/006893.html 'Yep. Essentially the programmers "steal" the presentation/view layer from the designers and convert it to "code".' http://lists.zope.org/pipermail/zope-dev/2000-September/006958.html OK, point taken, but it's not quite that simple. In the end, isn't that why artist do design, and coders code? One of the primary purposes in a complete Content Management System is to distill the presentation standard in a way that can be "layered" over any content. This principle doesn't stop at a clearly delineated "visual" line. Leaving the page layout "as is", which is what it sounds like you are suggesting, is even worse than doing the job right at the "cast into code" stage. If you leave the ugly HTML ugly, it will still be ugly next time it gets updated, but it will be much less useful in the meantime. Worse, it's likely to get uglier over time. Have you ever seen a baby rhinocerous? To me the real solution is to clean up the layout, converting hard coded "virtual" lists into real lists, etc., while painstakingly preserving the visual design. That clean, codified version can then be leveraged to the utmost during it's production life, and still be fed back to the designer at design update time. This can be easily done today in the form of a static HTML file, simply by calling the Zope URL of the base template, and hitting "save as". With the proposed xmlc-ish Template, the "snapshot" step should not be needed, which is great! Granted, if the person who distills the design into clean, reusable HTML / DTML / XML hasn't done the job well, incorporating the changes of the updated version may well be a nightmare. On the other hand, if this crucial step is done well, adapting the base template to match the "new vision" should in fact be much easier the second time. I think a large part of the confusion comes from where we each draw the conceptual line regarding what is "visual" and what is best handled as "code". An anchor tag is, after all, just a pointer to some related stuff, not the actual physical location of anything. If making it easy for visual folks to avoid this basic fact is the driver here, there's a much larger problem looming in the immediate XML future . . . Also, the idea of presenting a place holder sounds a lot like : "As for cases where a dataset is displayed, such as by a ZSQL query, perhaps a single "dummy" row, or cell, could stand in for design purposes." http://www.zope.org/Resources/Mozilla/ZWiki/IDEs Is that what you mean? Is the "dummy" stuff intended to resemble the final content, or just to mark an insertion point? Might it be possible to make place holders in the form of anchors (links) to DTML Methods, or other appropriate forms of native Zope elements, so that DreamWeaver, et. al. can pull down a "real" item, rather than having a hard coded "stuff goes here" label? That sounds advantageous to me, in terms of validating a visual design. Groping toward grokking, Jerry S.