Yanick Duchesne writes:
a) The contact manager will hold information for contacts(people) within organizations(companies); organizations will be categorized by predefined industries, etc. I am not sure how to model this; I am still a bit confused about how to approach a problem in Zope; it's so different... My first idea was this:
- Create an 'Organization' ZClass, in which there is a 'Contact' ZClass - Create an 'Industry' ZClass
Then:
- Create an 'Organizations' folder (contains Organization instances) - Create an 'Industry' folder (contains Industry instances)
Now, my question is this: how do I relate an organization instance to an industry instance? Looks for me as if an organization has a property containing the associated industry name. How do I materialize that possibility through the UI - I mean, how do I show the different industries in a listbox in the Organization's create/update screens? I am still quite confused about how objects in given folders have access to objects in other folders. Could someone help me on this - an example may be? "industries.objectIds()" will return the list of id's in the folder "industries" (provided "industries" is accessible by acquisition in the current context).
Reading the official Zope book or URL:http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html may help you answer such questions.
b) Objects, references and ZODB
Suppose I successfuly assign an industry object to an organization object, how is that persisted in ZODB? I mean, does the organization object only keep a persistent reference to the industry object, or does it copy the industry object entirely? What is the proper way to handle such cases in Zope? Copying the industry object would be a bad idea.
Logically, the industry object exists independent from the organization. Therefore, the organization should only reference it but not have its private copy of it. As suggested above, you would give the organisation a property "industry" that contains the name (aka id) of the industry object.
c) "mutable sub-objects should be treated immutably" - from a ZODB point of view.
I am not sure I completely understand this (I understand mutable and immutable allright, but I do not see what makes a mutable object being treated immutably, and how/why it affects ZODB). Python, per se, does not support persistence.
To get persistence, Zope objects inherit from class "Persistence". This class tries to detect changes to an object, as, when the object is changed, the modified state must be made persistent. The class detects when you directly change an attribute of the object. Thus: o.attr= xxx is detected. However, if an attribute value is mutable, you can change the attribute value without changing the object: o.attr.append('xxxx') would append 'xxxx' to "o.attr" (assumed, this is a list) without any change to "o". The persistence machinery would not detect, that "o" has been changed and a new value must be made persistent. The change would probably got lost eventually. There are two options: 1. avoid such modifications (treating mutable attributes as immutable) in the example above, you could use alternatively: o.attr= o.attr + ['xxxx'] You recognize the explicit assignment? 2. tell the persistence machinery about the change. You do this by setting an attribute to a true value. I think, it is "_p_changed" but it might have a slightly different name. I think, 2. is the far superior option. Dieter