Relationships between classes and objects¶
How to use references, associations, aggregations and compositions
With aggregations, compositions and associations you define where your new type will show up, what it might contain and to which content it can point to.
There is virtually no limit on how many aggregations, compositions and associations you can attach to a class.
Aggregation means: This content can exist global and in
this container. The container class that gets the empty
rhomb (diamond) attached is derived from BaseFolder and
is set to the class that is attached to it. If more than
class is attached to one class by aggregations the
is extended accordingly. The attached class keeps the
Compositions are used to model parts that exist or live
and die with their associated owner. So the code generated
is similar to the one generated by aggregations, but with
one major difference: The attached classes are only
allowed to be generated in the folderish type of the class
they're attached to (this is done by setting
in the factory type information of the class).
References are used to store the relation of an object to other objects.
Each content type that derives from
is capable of being referenced. Objects from such a
content type have an UID (Unique Identification) that's
unique throughout the whole Plone site. Therefore
References don't break if you move referenced objects
around in the site.
there are two possible ways. The by models-design clean
way is to use directed associations. Another possibility
is to define References as class-attributes.
An directed association between two classes generates a
in the class where the association starts.
itself is named after the association's name.
The multiplicity defines if the allows a 1:1 or 1:n relation.
This only results in validation on the field. References at all don't know anything about multiplicity, so this is only a check on userinterface-level.
All other field settings are taken from the association's end, including information how to generate the widget. By default a ReferenceWidget is used. You can use tagged values on the association's end to define label, description, a different widget-type, schemata, etc. like you do it on a field (on a class attribute).
The big drawback of using associations to create ReferenceFields is that they always get attached to the end of the schema and there is no way to change that in the UML diagram. So if you need order in your fields read the next section.
You can define an attribute with the type reference. Then you can apply any needed tagged values to it.
keys of interest are:
allowed_types: needs a list of allowed types
multiValued: set to 0 to only be able to select one object to reference to
relationship: name of the relationship in the reference_catalog
The benefit of using an attribute to define the reference is that you can define the place in the schema where the ReferenceField will show up.
Sometimes it's needed to store information not in the origin or destination class, but in the reference itself. UML has a notation to model this: association classes
ArchGenXML support them automatically. When a model includes an association class, two things occur:
- A new content type is created, named like the association name
The generated ReferenceField has a new attribute
defined like this:
referenceClass = ContentReferenceCreator('My_Association_Name')
This causes that the class of the reference instances is
Archetypes.ReferenceEngine.ContentReference, a subclass of it that has a new method:
getContentObject(), that return the content inside the
The same effect can be reached without association
classes, by defining a content type and then adding the
tagged value to the association (although I haven't been
able to make this work).
To create the reference via code, use a special form of the addReference method:
origin = <the origin content> destination = <the destination content> assocName = <the association name> origin.addReference(destination, assocName, referenceClass=ContentReferenceCreator(assocName), attr1=value1, attr2=value2...)
(where attr1, attr2... are the attributes of the association)
To read the data, we can't use the origin.getRefs(assocName) method, as usual, because it returns only the destination objects. One way to read it is by using the reference_catalog tool:
from Products.CMFCore.utils import getToolByName tool = getToolByName(origin, 'reference_catalog') refs = tool.getReferences(origin, assocName) if not refs: return  else: return [(ref.getContentObject(), ref.getTargetObject()) for ref in refs]