Relations form an important part of any semantic data model and it is important you understand the pros and cons of the three base types that exists in WAF.
Node relations
This is a two way relation between two content classes. It supports “one to one”, “one to many” and “many to many”. The actual relation is stored in a table separately from the content class table. This makes it possible to constrain the relation to any combination of content classes. The relation can be both dependent of both content culture and revision. You can relate an unlimited amount of contents. The actual property is shown as a paged list in the edit interface. The relation stores the order in which each item is related. A node relation supports join queries.
To define a node relation you start by defining the actual relation independent of the content properties. This is done in the definitions module under “Relations”. A special class is created for the relation, this class has methods you can override to add custom validation rules etc. The definition of a relation consists of the following:
- OneToMany / ManyToMany: Select the appropriate type. Select “OneToMany” if you want to define a “OneToOne” relation. The key difference here is that an OneToMany relation automatically updates the parent properties on all siblings.
- Parents: This is a list of the content classes that are legal as parents. Each listed class will include inherited classes as well.
- Children: This is a list of the content classes that are legal as children. Each listed class will include inherited classes as well.
Once the relation is defined you must add relation properties to the relevant content classes.
The relevant property classes are:
- ParentNodeRelationPropertyClass
- ParentsNodeRelationPropertyClass
- ChildNodeRelationPropertyClass
- ChildrenNodeRelationPropertyClass
The disadvantages with this relation type are:
- It is slightly more complicated to set up and that the edit interface only shows a list of related items.
- To edit related items you must click on each item individually and open a new window.
- You can only relate from one content class to another. You cannot add a relation property to an inner content.
A sample of the edit interface:
Inner content relations
This relation type is designed to handle data such as content paragraphs in a page. Typically you want to be able to edit all paragraphs within one edit page in the edit interface. You may also want to give the user a few paragraphs type to choose between. One for images, one for mainly text, quotes etc. This could of course be achieved by adding a series of fixed properties to a normal content class, but it would be very limiting. The user would not be able to determine the order of the paragraphs or the number of paragraphs of each type.
An inner content relation is a relation to a set of classes called inner contents. Inner contents are very similar the content base class, but they can only exist as part of a normal content. They do not have properties for things like template, access control etc. These properties are derived from the base content they belong to.
An example of the edit interface of inner contents:
Collapsed:
Expanded:
An important feature of inner contents is the ability to add inner content relation fields to inner contents. This enables you to create a tree structure of inner contents within one content.
A variety of inner content relations is the file folder property. This uses inner content relations to relate to a series of upload files. For each upload file an inner content of type InnerContentFile is created. You may expand the built in type InnerContentFile by creating your own inner content class that inherits from InnerContentFile.
Node parent relations
This relation type uses an IntegerDataValue to store the NodeId of the node you are relating to. The advantage with this relation type is that it is very simple to set up and that it can be used from within inner contents. The disadvantage is that is its one way. There is no opposite property for the child nodes. You relation does not support join queries either.
In the interface the property looks like this:
