[Zope] application design questions

[Paul Winkler]

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