On Thu, 20 May 2004 23:48:44 -0700 Allan Miller <amiller@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