Newbie Questions - many-many relationships? Zope 2 or 3?
Database Question Hello, I'm a newbie, so this is a newbie question! I am currently preparing to build a web application for property lettings, and I'm very interested in what Zope has to offer. The application will need to recognise a number of different objects, such as "houses", "prospective tenants" and "property owners" (the latter of which I may implement as user types, which would allow these people to log in and amend some of their own information.) I'm very interested in the Object Oriented way of doing things; for example, I'm thinking about implementing houses as a folder-ish object, so it would be able to contain photos of the house in question. The biggest stumbling block I am facing is how to do something "Relational" in an OO environment. 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! Having a look through past threads on this mailing list I've noticed a few references to mxmRelations (http://www.zope.org/Members/maxm/products/mxmRelations) which seems to match up - have I got the right end of the stick? Before I jump in with this I'd appreciate any advice or guidance you could provide - it'd be greatly appreciated. While Im on, Ive 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? Id greatly appreciate any guidance that can be provided on these subjects. Thanks in advance, Jim ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Jim Vine wrote:
Having a look through past threads on this mailing list I've noticed a few references to mxmRelations (http://www.zope.org/Members/maxm/products/mxmRelations) which seems to match up - have I got the right end of the stick? Before I jump in with this I'd appreciate any advice or guidance you could provide - it'd be greatly appreciated.
Use Plone and references instead ;-) -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science
On 6/17/05, Jim Vine <jim_a_vine@yahoo.co.uk> wrote:
I'm very interested in the Object Oriented way of doing things; for example, I'm thinking about implementing houses as a folder-ish object, so it would be able to contain photos of the house in question. The biggest stumbling block I am facing is how to do something "Relational" in an OO environment. 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!
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!
Having a look through past threads on this mailing list I've noticed a few references to mxmRelations (http://www.zope.org/Members/maxm/products/mxmRelations) which seems to match up - have I got the right end of the stick?
Relation products often are aimed at making arbitrary relations between different objects. it's cool, and useful. It may be overkill in this case, unless you want to for example have different types of owners. Then it fits perfectly. http://zemantic.org/ Is the relations tool that seems to emerge as the preferred one in the zope3 environment.
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?
For applications development, zope3 is definitely recommended. Zope2 is only recommended if you you want to use a CMS application, like Plone, CPS, or something else. There isn't one for zope3 yet. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
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 Im on, Ive 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.
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 Im on, Ive 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).
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.
Yes, it should have triggered mine too, as I wouldn't do that in my own apps....
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
It is. Andreas -- You will inherit millions of dollars.
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
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/
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
Hi, I hope it's not considered "bad form" to answer ones own questions on this board, but I think I've got it sussed. Reading through the ZWiki source from http://svn.zope.org I noticed the following line in the implementations: from zope.app.container.contained import Contained I added this to mine, and it has cleared up the error a treat. Thanks, Jim PS - In scrabling around the net trying to solve this I read somewhere (I think it was a Python Tutorial) the following advice: "Use the source" (Luke...) I can strongly recommend to any other newbies looking for examples to take a look at to try out ZWiki - it's got a reasonably small number of interfaces and classes, so you can get your head around it, and it covers useful things like containment. --- Jim Vine <jim_a_vine@yahoo.co.uk> wrote:
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
___________________________________________________________
How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com _______________________________________________ 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 )
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.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/
Hi Jim, Jim Vine wrote:
I’d greatly appreciate any guidance that can be provided on these subjects.
I know a lot has been said since your original query, but re-reading it I was surprised that no one had asked a fundamental question: - "If the data is structured in nature and fits the relational model well (e.g. is well defined), why not use an RDBMS for the data, and Zope/Plone for the UI? I do full-time development of web-based RDBMS applications in Zope and Plone (MS SQL and Firebird), and I have the following observations: - - By putting database-related complexity in the database, where it belongs IMHO, you may find (as I have) that the complexity of what you need to accomplish in Zope is reduced to the point where the ZMI approach is entirely appropriate. - You will find yourself working very hard to implement a relational database in the ZODB, compared to interfacing to an RDBMS. If you need one, I'd use one - instead of writing one! ;-) YMMV and all that - I /am/ an RDBMS zealot (see Fabian Pascal's writing for the mindset!), and I am /not/ a Python wizard (although my Python-Fu grows stronger by the day due to immersion in Zope...), so my choice of approach was strongly influenced by my starting point. -- Regards, PhilK Email: phil@xfr.co.uk PGP Public key: http://www.xfr.co.uk Voicemail & Facsimile: 07092 070518 "You'll find that one part's sweet and one part's tart: say where the sweetness and the sourness start." - Tony Harrison
participants (5)
-
Andreas Pakulat -
Jim Vine -
Lennart Regebro -
Max M -
Philip Kilner