I was reading through last months CMF list archives, and saw some similar sentiments; I would have to disagree, as someone who has worked with both ZPT and DTML enough to know the ups and downs to both. Here's my take, for what it is worth. I like ZPT... Something important to consider, IMHO, is how many people are stirring the pot. If you have a group of folks working on a site, including developers, designers, and other folks, you are bound to run into problems with unnecessary overlap of domains. In my projects, I want to: - insulate designers from code, which they can cause problems with. - insulate myself, as a coder, from the html, which often clouds the implementation - force designers to write well-formed HTML; you would be surprised... When there is a need for overlap, I write "widgets" in dtml that are used by ZPT, instead of using ZPT macros/slots. I think this is an ideal balance. I really think there are problems with the scalability of a project when you have the following combination: - Code mixed with presentation - Multiple people working on your site. My company has used ZPT for a few projects, and also a previous all-DTML project; I think I've had faster project turnaround times with ZPT, and the templates are easy to maintain, even if people unfamiliar with TAL attributes look at the html. We don't use WYSIWYG tools, we prefer to use tools like Homesite, and I still think ZPT has advantages for this audience. The only confusing things for ZPT newbies I have experienced: - non well-formed html (unescaped entities) has problems; a lot of designers still have problems with this, but that is because web publishing systems are generally too forgiving. - Rendering of macros in the source of a document that uses a METAL macro; I'm undecided of this personally, though I have done it both ways. Pages should be a working document; anything that is less-than a page should be done in DTML instead as a 'widget' or done using METAL macros that remove this limitation (more pure, but also more confusing). I think this hybrid templating model makes sense, provided that the people creating the dynamic 'widgets' in DTML for use in ZPT pages are more developer-type folks with an ability to be able to use DTML and TTW python scripts. Reality likely dictates that you will have sites using ZPT, METAL macros, DTML, and TTW ptyhon scripts sometimes just to render a single page, but at least this keeps things fairly compartmentalized, which is especially good if you have multiple people working on a site. The ability to include mockup data in the template is also good, esp, when using 'wdigets' created in dtml... Also, pages don't get out of sync because layout (nav, etc) should be done using METAL macros. We have a ZPT page called masternav.html in our ZPT-based sites, which contains a METAL macro that wraps the content-cell of a page rendered in other ZPT pages. We use this, and stuff definitely does not stay out-of-sync, since there is one source for the navigation for a site. The biggest problem/learning-curve to ZPT is also its greatest strength, and that is METAL macros, and I personally think that serious use of these requires either: good aptitude for reading docs and some time to play with trail-and-error, or good training with plentiful examples for design departments using ZPT for template production. And using ZPT is a lot less crazy than using something like XSLT for presentation, without the mess of mixing HTML with non-HTML-like code (ASP, PHP, JSP, and even DTML). I think it strikes a good balance. Sean -----Original Message----- From: Lee Braiden [mailto:jel@ntlworld.com] Sent: Thursday, January 03, 2002 3:09 PM To: ZOPE Mailing List Subject: [Zope] Templates a step backwards? Hi guys, I'm fairly new to ZOPE, and although I've stuck my toes in the water a few times now, I'm only starting to seriously look at it, and especially the new CMF/Templates/etc. I see why all this new stuff is being developed. What I'm not sure about is page templates. Are they really a good option, if you can life without WYSWYG editing? I mean, surely they're a step backwards, in that every page has to basically be a working document. Doesn't that bring in redundancy, with multiple pages holding the same basic layout, and having the potential to get out of sync? If not, then great -- I'll look forward to using them. But in that case, what have I missed? - Lee.