I'm sorry for my ignorant use of the terms relation
and relationship. I'll try to use the terms more
appropriately in the future.
I think I understand where I've become confused. In
many of the persistance mechanisms I've looked at
references to other objects were handled specially,
and had rules associated with them. I think I
understand now that it is mearly just a design
problem, nothing having to do with zope. When
creating objects I will need to pass the reference to
the other object, or have a manager for the
I had assumed that objects were somehow self aware
in some way of the zope environment, and therefore
coule access it. I appologize for any time I might
have wasted. The solution is simpler than I had
--- Leonardo Rochael Almeida <[EMAIL PROTECTED]> wrote:
> On Fri, 2003-10-10 at 00:46, Jason Corbett wrote:
> > Thanks for your reply. I've actually been
> thinking in
> > an object oriented form for a while. I've looked
> > implimenting this project in Java using either
> > prevailance or a object persistence model that
> > to a RDBMS. I like the idea of zope, so maybe I
> > should clarify my question:
> > How does an object in zope know where it sits in
> > hirearchy, and how does it reach other objects.
> > That's what I'm really looking for, I can probably
> > code the rest of the parts.
> In my experience, you should put an object inside
> another if and only if
> they have an explicit containment relationship, e.g.
> a car has 4 tires
> and a steering wheel. The steering wheel can belong
> to (at most) one car
> at any moment in time, so it would make sense to put
> the steering wheel
> object inside the car object. The same is not true
> of, for instance,
> students and school classes. In this case you either
> store a reference
> to the student in the school class (eg a student id
> in a "lines" or
> "tokens" property) or you create an object to
> represent the
> class-student relationship (for example an
> enrollment) and store it
> Tip: always use methods that return the objects you
> need, for instance
> aSchoolClass.students() this way you can more easily
> change the storage
> of the relationship information when you change your
> mind. And you will
> change your mind a lot of times.
> Tip2: a lot of times you'll implement the above
> mentioned methods as
> catalog queries, like: what objects in the other
> side of the
> relationship reference me?
> Tip3: look mxmRelations
> Cheers, Leo
> PS: just because this is a pet peeve of mine, I'll
> explain that a
> "relation" and a "relationship" are two very
> different things.
> "Relation" is the mathematical term for a table, a
> set of distinct
> elements (rows) with the same kinds of attributes
> (columns). You can
> think of a relation (table) of cars, or a relation
> (table) of students.
> Relational databases get their names because they
> store relations and
> allow you to do some relational algebra with
> (usually) SQL.
> A relationship, on the other hand, is a link, or
> association, between
> RDBs allow you to model relationships relatively
> easily thru either
> relational operations:
> SELECT * from cars, steering_wheels
> WHERE steering_wheels.carId = car.carId AND
> steering_wheels.wheelType = "sport"
> or by storing relationship information in relations
> (sometimes known as
> "link relations" or "link tables"):
> SELECT * from enrollments, classes, students
> WHERE classes.classId = enrollments.classId
> enrollments.studentId =
> students.studentId AND
> students.studentName = "Jason Corbett"
> But RDBs themselves have absolutely no concept of
> So, next time you read the word "relation", think
> "table" :-)
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -