On Tue, Oct 30, 2001 at 04:14:10PM +0100, Reinoud van Leeuwen wrote:

after playing for some time with Zope, it is time to rewrite my application from the bottom up. However, I am looking for some high-level design guidelines.

I wish I knew of some existing docs like this. :(

Most of the documents are of the form "how to get product X working", but I am looking for high level documentation about:

- how to make sure the application is portable and behaves nice

One thing that bit me: Don't rely on bobobase_modification_time. If you export an object from one zope and import it into another - guess what, its bobobase_modification_time gets set to the import time. I really wish import had an option like cp -p (preserves all attributes). I also wish I had a good workaround. :(

- what functionality to put where (database/python/dtml/ZPT) - what data to store where? (right now I put the relational data in Postgresql, and large things like pictures and PDF's in ZDB) - general to do's and don'ts - how to set up a real nice distinction between presentation and functionality

The following is ust plain old good programming advice, but for some reason I (and others) tend to forget it in the context of Zope. Maybe it's because there's a mental gap between "web page" and "class instance". In Zope, a web page *is* a class instance. I'm currently finding that it helps to remember that the O in ZOPE stands for Object. I think of a folder as being like a module, and everything else is an object or method. I try to break everything down into small, simple templates and scripts, and use folders to organize them. Any time you write the same python expression in two different ZPT or DTML pages - NO MATTER HOW SIMPLE - it should probably go in a separate python script with a descriptive name. The same goes for templates, whether DTML or ZPT. Don't duplicate code, whether it's logic code or presentation code. Use folders to organize your scripts and templates just like you'd use modules to organize classes and functions in any object-oriented project. It makes your path names a bit longer, but I find the organizational clarity helps. The point of all this is that it saves an enormous amount of time and headache when you want to change some behavior and realize you duplicated the logic across several pages and now you can't remember which they are. Or you think you remembered all of them, but actually you missed one. -- paul winkler home: http://www.slinkp.com music: http://www.reacharms.com calendars: http://www.calendargalaxy.com