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

[Allan Miller]

On Thursday 20 May 2004 11:21 pm, Terry Hancock wrote:
> On Thursday 20 May 2004 10:19 pm, Allan Miller wrote:
> > The applications and Products I've seen define one or two application or
> > Product classes, and consist of a lot of ZPT's that are essentially forms
> > paired with, or posting to, PythonScripts.  I wonder - am I missing
> > something?  It seems like the applications are organized almost
> > exclusively around ZPT's and PythonScripts, with no use of business
> > objects/classes, for example.  Is this the unusual approach?
>
> I think you'll find it's fairly common for products that started life as
> ad-hoc collections of scripts created using the "through-the-web"=TTW
> interface.  And because that's pretty easy, it wouldn't surprise me to
> find a lot of them.  But there are certainly some very popular products
> that use OO design.  And Zope itself is very OO.
>
> > Can anyone point me towards some
> > applications that are considered well designed - make good use of
> > programmer defined (espcially domain) classes?  How about some articles
> > on  good Zope application design practices?
>
> Please understand that I'm probably at least as clueless about Java
> as you are about Python. ;-)  So I'm not sure I totally follow you -- there
> are somewhat different object-oriented design philosophies that prevail
> in the Python community compared to the Java community.  And some
> terminology doesn't translate well.
>
> In Python you'll find that objects (specifically "class instances") are
> sometimes used where you would probably use a class in Java.  There's
> less distinction between the two in Python, since objects can dynamically
> add and remove methods and attributes.  The "Interface" concept has been
> introduced into Zope and is used to fill the role of what you might call
> an "abstract class".
>
> I don't know about "considered well designed", but my VarImage product
>
> (SF download available from: http://sourceforge.net/projects/narya-project
> )
>
> is a fairly small example of an object-oriented Zope product (at least it's
> more OO than your description of products you've seen).  It also
> demonstrates a simple form of component architecture to handle operator
> plugins -- kind of an experiment I used to teach myself the concept,
> actually.
>
> There's also the "poll" example in the ZDG and some other tutorial products
> that demonstrate the general approach I've used.
>
> (Narya itself is a much larger OO product, but as it's not yet functional,
> I wouldn't recommend it as an example -- too many broken things).
>
> No doubt other people can find other examples of OO product design.  You
> will of course, want to check out the products that come bundled with
> Zope -- I suspect most of those would qualify, too.
>
> Cheers,
> Terry
>
> --
> Terry Hancock ( hancock at anansispaceworks.com )
> Anansi Spaceworks  http://www.anansispaceworks.com


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.