I came up to the idea that for people wanting to use Zope for high trafficked sites, and thus are looking for every bit of performance out of their web applications, ZPT would probably may not be a choice at all. I've recently tested Plone (the CMF skin built entirely of ZPTs) on a Pentium IV @ 1.7GHZ plenty of memory, and generally speaking I had this sensation that in despite of that horsepower, every page took a little bit of time to render while some pages took from half a second to two seconds. (DTML based pages, no matter how complicated they were, rendered almost immediately ). Now, take that and multiply it for 20 or more simultaneus hit responses and you'll find out that you'll need more horsepower than the average in order to provide a pleasant session for all the users. By the way it's not Plone's fault. I see ZPT more like a marketing strategy and hence the closing of the gap between designers and programmers looks like a huge selling point ( provided other less elegant scripting languages like PHP do have more attention than Zope/DTML/ZPT/Python from web design suites like Dreamweaver.) Of course in the future, when computing power wouldn't be a concern, this effective separation of code and html will be a key feature. Just my two cents. Ausum ----- Original Message ----- From: "Thomas Guettler" <zopestoller@thomas-guettler.de> To: <zope@zope.org> Sent: Thursday, August 08, 2002 6:17 AM Subject: [Zope] My Way of Zope Programming
Hi!
After using Zope more than one year I want to share my experiences with you
That's what I think:
0. Learn python
1. Don't programm Zope TTW (Through the web) This applies if you have a small group of developers. If you have many developers who know HTML editing TTW might be for, but then this text does not apply This means: Use Python Products
2. Don't use ZPT, DTML or ZClasses. I spent to much time searching for the line were the error occured. Since I use python I no more have theses problems. Example: def foo(self, REQUEST): "docstring" .... ret=[] ret.append(self.root.standard_html_header()) ret.append(""" <your tag> %s <foo>%s</foo> </your_tag> .... """ % (var1, var2)) return string.join(ret)
3. Don't use acquisition. The only part where acquisition is usefull is for the standard_html_header See the example above how to do it without it
4. If you are starting a new project use ZODB for the storage and not a relational database. Soon directory storage will be stable and you have the latest storage solution
5. Use BTrees. They are very scalable. But pay attention: The keys must all be of the same type.
What do you think about it?
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )