[Zope] Re: Good Object-Oriented Design Approaches For Zope Development?

[Casey Duncan]

On Thu, 20 May 2004 23:48:44 -0700
Allan Miller <amiller at a2software.com> wrote:
[..]
> Terry - thanks for your clear, helpful, and very thought-provoking
> response.  I will definitely look at the resources you mentioned in
> your message.  What you wrote made me see that I have to learn to
> start "thinking in Zope," understand specific Zope idioms and
> approaches to problem solving.
> 
> I think my original question wasn't specific enough.  Perhaps an
> example would would make things clearer.  One category of products I
> looked at were Zope discussion board products.  I expected to see
> classes such as User, Forum, Posting, etc., that model the objects
> that comprise a discussion board.  Instead, I often saw a ZPT form for
> adding a user, and a PythonScript - something like addUser.ps -  that
> builds a dictionary of user properties (username, password, country,
> etc.) and adds it to the container (folder?) in which the PythonScript
> resides.  Maybe I need to get used to the idea of systems being built
> around Zope in folders, but I was looking for at least a User object
> to encapsulate the properties that were stored in the dictionary, as
> well as some methods to access them and model User "behaviors."  I'm
> not trying to be an abstract O-O "purist," I just think that having
> classes that reflect the problem domain makes it a lot easier to
> understand, and hence modify or extend the system.  Thanks again for
> your response.

In Zope there are basically two modes of development: 

- Instance space development (as you describe above) takes existing
"framework" objects like folders, files, property sheets and glues them
together with templates and scripts. Also many instance space apps use
relational databases to store and retrieve data via ZSQL methods. 

- Filesystem product development describes the model using classes, by
inheriting from framework classes rather than just reusing instances.
There is also an instance-space way to do this via ZClasses, but these
are best avoided IMO. On top of these model classes, templates and
scripts are used for the "view" and "controller" aspects of your
application. These scripts and templates are typically "environmentally
inherited" using Zope acquisition. The CMF contains a "skins" mechanism
which formalizes this a bit more and makes it more controllable.

Most problems can be mapped to either space. In general instance space
is good for prototyping or one-off mini applications. Products are best
for generalized components (or even whole applications) that can be
reused. The two techniques are often (maybe even always?) used together
in Zope. You start with a filesystem model and layer policy and look and
feel on top of it using templates and scripts. These scripts can be in
the ZODB or the file system (if you use CMF skins).

To use Zope effectively you must know both techniques. Often people
start with instance space dev and either never leave it or move on to
filesystem coded products. The latter is more formalized and thus may
better fit what you may be used to from Java. Pretty much all of it is
more formal and structured then Perl CGI ;^)

hth,

-Casey