RE: [Zope] Re: Java re-invents DTML :-)
This is well put. I think this argument is also true of designers who don't use WYSIWYG tools as well, for the same reason, I think: round-trip design involves iterations of programmers messing with the behavioral and integration aspects of templates while the designers want to keep changing the design over time. As each of these steps happens, DTML makes the two have to communicate more and correct for missteps more, while ZPT allows for each to operate more independently and still modify the code somewhat independently, without the need to reverse-engineer and reintegrate. This is the case even when the designers use tools like Homesite or a text-editor instead of GoLive or Dreamweaver. Tech staffs have limited resources, and to be required for close technical consultation on each presentation-layer redesign is an unnecessary drain on technical resources. ZPT helps minimize this by minimizing the need for re-integration. Sean -----Original Message----- From: J Cameron Cooper [mailto:jccooper@jcameroncooper.com] Sent: Tuesday, February 18, 2003 3:38 PM To: zope@zope.org Subject: Re: [Zope] Re: Java re-invents DTML :-)
DTML just doesn't scale to non-techies or content people who are talented at HTML, but not 'programming.'
Being exactly what you are referring to, ie: someone who knows html, but not programming, I have to disagree. I tried Zope initially BECAUSE of it's tag based scripting language. I found it very easy to learn, and granted, I have encountered some syntax issues that were a problem for a while, but searching on zope.org and asking for direction from list members, everything has worked out just fine. I constructed 26 virtual sites with Zope and DTML. I have also looked at ZPT and found it rather confusing. I guess maybe it's just the way I'm wired or how I process information, in any case, since we're not all the same, I feel that continuing to offer both solutions would be the most appropriate course.
You're right: if you have good control over all the people working on your site (i.e. by yourself, with other of the Zope-savvy) either templating language can work fine. DTML, being straightforward, might even be easier (depending on if you've been trained to think XMLishly or not.) Note of course that Page Templates *look* a lot more obscure than they actually are. But throw in a couple designers with WYSIWYG editors and all hell's out for noon with DTML, so far as round-tripping your design is concerned. If that'll never happen, don't worry about it; if it might, or will, think very hard. And test the likely tools. There are people who think best in both DTML and ZPT modes, and I don't think it's a bad thing to have both lying around, so long as it is clear that "best practice" involves Page Templates (which I think it does), and the reasons for that are explained. --jcc _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
----- Original Message ----- From: <sean.upton@uniontrib.com>
This is well put. I think this argument is also true of designers who don't use WYSIWYG tools as well, for the same reason, I think: round-trip design involves iterations of programmers messing with the behavioral and integration aspects of templates while the designers want to keep changing the design over time. As each of these steps happens, DTML makes the two have to communicate more and correct for missteps more, while ZPT allows for each to operate more independently and still modify the code somewhat independently, without the need to reverse-engineer and reintegrate. This is the case even when the designers use tools like Homesite or a text-editor instead of GoLive or Dreamweaver.
That's all true, but I think we're kind of missing a point in the whole discussion. Not everyone says let's all code in one single language and trash the other. Actually we're saying how lucky we are that we can seize both of them for what they're worth. The other thing that in my opinion we might be missing, is that a dynamic portal is not necesarily made out of logic and whole page templates. I'm convinced that there is at least one more stage in-between made out of page fragments that can be handled as a real object (pagelets). Think of a search results page, or a folder contents one. Don't you think there's something that can be automated there that could save valueable developers' time, by means of an object whose mission was to take over the repetitive coding (across different sites) and to deliver the page fragment (the rendered columns and rows in a table) we just need in that particular page? Something like dtml-tree already does, but movable, reusable and highly configurable in a dedicated UI, and completely independent of macros of any flavor?. Well, that's the kind of stuff I'm working at for what I believe DTML and PythonScripts are just better suited than ZPT. Ausum
Tech staffs have limited resources, and to be required for close technical consultation on each presentation-layer redesign is an unnecessary drain on technical resources. ZPT helps minimize this by minimizing the need for re-integration.
Sean
participants (2)
-
Ausum Studio -
sean.upton＠uniontrib.com