Hello, Being new to zope, I'm having trouble wrapping my brain around how to structure people objects in our dept. Perhaps this is a common modelling problem which someone has done before: We have people, and people may have many different roles. So for example, a person can be a lecturer and also a fire warden. Now each person has common properties, and then more specific ones as a lecturer or fire warden. So I create a container for common persons, and then containers for lecturers and containers for fire wardens. Each is its own class, with its own properties. Now with my brain still full of relational data base concepts, I use each object's id as a key, so to look up lecturer Joe's telephone number, I say in the context of lecturer, joe.people.joe.telephone which is very ugly and path dependent.... furthermore, if Joe the lecturer has a specific phone number then I want that, not Joe the person's number. Another way could be to have a getTelephone() method and use aquisition, but again, that would be structure dependent - all lecturers and firewardens would have to live in containers within the People container. So can an object 'inherit/acquire' another object's properties without that object being a subclass of the other? Should I forget this altogether and use ZCatalogues? Is there something really obvious staring me in the face? Thanks for any pointers. Roman. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Roman Bogoyev, Computer Systems Manager, email: roman@maths.uwa.edu.au UWA Maths, 35 Stirling Hwy, Crawley, phone: +61 8 9380 3379 Western Australia 6009 fax: +61 8 9380 1028
Roman Bogoyev wrote at 2003-9-22 17:24 +0800:
... So I create a container for common persons, and then containers for lecturers and containers for fire wardens.
Why do you have containers for the different types of persons? A more natural thing would be to have just one container and use catalog searches (or "topic"s) to determine the subsets as necessary.
Each is its own class, with its own properties.
That fine! With more specific classes deriving from more abstract classes... Dieter
participants (2)
-
Dieter Maurer -
Roman Bogoyev