Thanks to those who posted suggestions - certainly gave me a few things to think about. Unfortunately I was left with one "use Zope 2", one "use Zope 3" and a "use Plone", but maybe that's just a reflection of the fact that there's more than one Zope way to skin a cat! (yeah, I know I've over-simplified the answers - no offence is meant!) On another thread (http://mail.zope.org/pipermail/zope/2005-June/159738.html), someone said: "The problem is that you develop using the ZMI. It's a bad pattern. Don't do it." but the Zope Book (2.7 version)'s chapter on Creating a Basic Application all seems to be through the ZMI. Now, Zope's original appeal to me was using the graphical interface provided by the ZMI to create a collection of objects which if you wire them up correctly will become an application, a view that I think is supported by the Zope Book. However, this view, and what I've read about Zope 3 seems to indicate that this way of doing things is deprecated. Am I correct here? Particularly, if I am building an app that I think I will want to add extra functionality to after it has been installed and is in use, is this a particular reason to avoid developing with ZMI? Say, for example that my Zope App in some way has a "House" object, which records the address, the owner, and a short description. Later on, I may wish to add further fields to record, say, the number of bedrooms, but the system is already in use - if I've developed in the ZMI, will this make it harder to make an upgrade? Now, if the answer to all of that is "yes", then I think that steers me away from the need for TTW development (TTW = Through The Web = ZMI, yes?) which steers me towards Zope 3. I'm interested by the suggestions on how to handle the relations.

Hmm, what I would start with is an attribute for a house containing a list of references to owners. And vice versa, each owner has a list of references to houses.

I had thought of this, but my concern was about how to make sure that the two records are kept accurate - basically the suggestion is to keep two records saying the same thing, which just triggers alarm bells with me. Another suggestion was:

Nah. You either let every PropertyOwner have a list of the ids of HouseProperty objects, or the other way around. Then you index this is the catalog so you can search. Tada!

I like the sound of this a bit better - just keep records in one place. So, if I've followed, I let the the house "knows" who owns it, and if I go to a certain owner's page and want it to give me a list of all the houses she owns, it would do a search through all the house records to see where she's mentioned. Thanks again for all the help so far - lots of food for thought. Thanks, Jim --- Andreas Pakulat <apaku@gmx.de> wrote:

On 16.Jun 2005 - 23:17:43, Jim Vine wrote:

...

Specifically, I've been scratching my head for a while about how to handle a many-many relationship: a property owner may own more than one house; conversely, a house may have more than one co-owner - consequently it's not appropriate to have either containing the other. I've googled for general information about handling many-many relationships in OO, and most of what I've come across has only indicated that it can be tricky!

Hmm, what I would start with is an attribute for a house containing a list of references to owners. And vice versa, each owner has a list of references to houses. Now in Zope references could be implemented via storing the URL of the house and references to Users could be stored via the username (the one the user uses to log in).

...

While I’m on, I’ve noticed that Zope 3 has been released. Is this now the recommended development environment, or am I better off sticking with Zope 2 for now, and porting my application once Zope 3 is a bit further down the line?

Read the archive, short answer is:

If you depend only on Zope, you don't want TTW and you want to write a file based product: Zope3 would be possible

If you need some existing products or if you need TTW-Code, then you have to stick to Zope2

Andreas

-- You're ugly and your mother dresses you funny. _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )

___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

On 21.Jun 2005 - 21:59:41, Jim Vine wrote:

...

Say, for example that my Zope App in some way has a "House" object, which records the address, the owner, and a short description. Later on, I may wish to add further fields to record, say, the number of bedrooms, but the system is already in use - if I've developed in the ZMI, will this make it harder to make an upgrade?

Such a change might not be a problem using ZMI, as you can freely add properties to any object. You'd have to supply the data for all existing objects though (but you'd need to do that when using a product too).

OK, so there are (at least) three ways of doing things in Zope: 1. Using the ZMI to build an application using standard objects (classes) 2. Creating new classes to use in your app through the ZMI. 3. Creating new classes to use in your app in Python. Most of the Zope Book concentrates on method 1, and the "Extending Zope" chapter is about method 2 - it mentions method 3, but says that it's beyond the scope of the book. I think I've convinced myself that the complexity of my app takes it beyond method 1, but I'm strugling to get my head around the implications of selecting method 2 or 3. Am I right in thinking that either of these will result in my building a "Product"? If I want to add extra feature to my product on the development server and then port them to the live server (with all the data on the live server being left in tact), will selection of either of these particularly help or hinder me in this? Apologies for asking so many questions, and thanks to those who have helped so far. I guess I'm just keen to start from the right place at the beginning, so save myself headaches further down the line. Thanks, Jim ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Hello again, So, following the recommendations from the board I have settled on "route 3" - developing a Python Product, using Zope 3. I've been refering a lot to the Zope 3 Book (particularly chapter 13 onwards) and have progressed somewhat. I've created a "PropertyFolder" class, which can hold Property obects, and following the example in the book I've been able to make it hold *only* Property objects. My "Property" class is proving a little more difficult, however. When I've tried to make it along the same lines as the "message" class in the book, I run into difficulties - it seems to be some sort of problem with inheriting from multiple classes / interfaces. My workaround has been that I can include my __setitem__.precondition within the main IProperty interface, and make that subclass from IContainer instead of Interface. This works for me, because I'm not going to want Property objects to contain other Property objects, but I really haven't been able to track down why it should work for the message board, but not for my classes / interfaces. The errors I was getting before my work around seemed to be indicating that it wasn't a container, although I was subclassing BTreeContainer, and implementing three interfaces (one and Interface, one and IContained, and one IContainer). Mostly this presented itself as Zope complaining about using __len__ on the object. (As I say, I have worked around this, and mention it mostly in case it sheds any light on the issue below...) My current problem, however, is proving harder to work around. I want my Property objects to be able to contain Images, and sets of attributes. (A typical set of attributes would describe what is in the kitchen). I have created interfaces IAttribSet(Interface), IAttribSetContainer(IContainer) and IAttribSetKitchen(IAttribSet); and classes AttribSet (implements IAttribSet and IAttribSetContained) and AttribSetKitchen (implements IAttribSetKitchen). I am using IAttribSetContained to create a __parent__ ContainerTypesConstraint. I have wired up the kitchen attrib set in .zcml files. When I 'turn off' implementing IAttribSetContained, my kitchen attrib set is working fine, in that I can add it anywhere, and edit it. However, when I try to add a condition saying where it can go (i.e. I only want it to be within Property objects) it correctly only appears as an Add-menu item within Property objects, but on adding it, I get an error, saying "AttribSetKitchen instance has no attribute '__parent__'". My Property and PropertyFolder objects are implemented as BTreeContainers. I'm really quite stumped by this, so I would appreciate any guidance that could be provided on tracking down the source of the errors. Thanks, Jim --- Lennart Regebro <regebro@gmail.com> wrote:

On 6/22/05, Jim Vine <jim_a_vine@yahoo.co.uk> wrote:

...

I think I've convinced myself that the complexity of my app takes it beyond method 1, but I'm strugling to get my head around the implications of selecting method 2 or 3. Am I right in thinking that either of these will result in my building a "Product"?

Yes.

...

If I want to add extra feature to my product on the development server and then port them to the live server (with all the data on the live server being left in tact), will selection of either of these particularly help or hinder me in this?

I don't know, because when I tried 2., it turned out to be quite complicated, and I never understood how to do it. So I did 3. And afterwards I have realized that even if you do understand how to do 2, the fact that you do most of your stuff in the restricted python scripts and dtml or ZPT, means that you have tons of limitations to go around.

In addition to that, you can't easily use any proper editors to edit the code, which is very annoying.

Method 2 (aka ZClasses) simply seem to offer exactly zero benefits, and loads of drawbacks.

Also, as mentioned earlier, unless you want to build your application on top of one of the Zope2 content management systems around (CPS, Plone, Silva, ...) you probably want too use Zope3 for your application development anyway. And then only method 3 (disk based development) is available.

-- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )

___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

On 6/21/05, Jim Vine <jim_a_vine@yahoo.co.uk> wrote:

but the Zope Book (2.7 version)'s chapter on Creating a Basic Application all seems to be through the ZMI.

Unfortunately is the correct word there.

Now, Zope's original appeal to me was using the graphical interface provided by the ZMI to create a collection of objects which if you wire them up correctly will become an application, a view that I think is supported by the Zope Book.

Yeah, me too. Turns out it's not such a hot idea after all. :) Disk-based products is the way to go (often just called packages in Zope3).

However, this view, and what I've read about Zope 3 seems to indicate that this way of doing things is deprecated. Am I correct here? Particularly, if I am building an app that I think I will want to add extra functionality to after it has been installed and is in use, is this a particular reason to avoid developing with ZMI?

Yes, that's a good reason to avoid it, because upgrading becomes problematic. Normally you want one development site and one production site, and you want to develop the code on the development site and then move it to the production site. But when the code and the site is the same, this becomes trickier.

Now, if the answer to all of that is "yes", then I think that steers me away from the need for TTW development (TTW = Through The Web = ZMI, yes?)

Yup.

I like the sound of this a bit better - just keep records in one place. So, if I've followed, I let the the house "knows" who owns it, and if I go to a certain owner's page and want it to give me a list of all the houses she owns, it would do a search through all the house records to see where she's mentioned.

Yup. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/