1. Bidirectional relations

When we created the field rel1_pages in the content area “Projects”, camindo CMS automatically created the counterpart field rel_projects in the area “Pages”. The two fields belong together and store the same relations – each from its own point of view.

Relation field	Content area	Target area	Stores …	Type
`rel1_pages`	`projects`	`pages`	the linked page of a project	n:1
`rel_projects`	`pages`	`projects`	the linked projects of a page	1:n

What rel_ and rel1_ are about

The name of an input field is bound to one type throughout the system: If the field title is of the type “Text” in one content area, it cannot be of the type “Number” in another. This is what makes it possible to search a field across several content areas – for example for a particular last name in the areas “Shop customers”, “Customer archive” and “Subscribers”.

To avoid naming conflicts, name prefixes are reserved for all types, e.g. txt_ for fields that store long texts and int_ for fields that store integers. The name of a text field can therefore never start with int_.

For relation fields, camindo CMS suggests a prefix in the field “Name” – in our case rel1_, because our relation is of the type n:1. We completed the name to rel1_pages.

The automatically created counterpart field is of the type 1:n. camindo CMS built its name from the prefix rel_ and the name of its target area projects: rel_projects.

The prefix rel_ is used for relation fields of the type n:m and of the type 1:n. You can find the reserved name prefixes of all types in the manual for administrators under Reserved name prefixes.

What n:1 and 1:n are about

The value before the colon refers to the area in which the field is created, the value after the colon refers to the target area.

Using the first row in the table as an example (rel1_pages): n stands for any number of records in the source area, the 1 after the colon for exactly one record in the target area. The relation field rel1_pages therefore stores at most one target record; that record, however, may be linked to n records in the source area.

The relation field rel_projects is of the type 1:n. It can store any number of records from the target area, but detaches them from other records in the process: This way, a project is always linked to exactly one page.

To better understand how the two fields work together, we will show the automatically created field rel_projects in the input form of the content area “Pages”.

Switching modules faster with the “Quick search”

So far, we have clicked our way through the modules to open the forms we needed. This time we will use the quick search:
Press Ctrl + G (or ⌘ + G on a Mac); a search field appears. Type area:pages and press Enter.

The detail view of the content area “Pages” appears right away. Switch to the tab “Input fields” and look for the field rel_projects.
So far, it is not visible anywhere: None of the three checkboxes (“Input”, “Search”, “List”) is ticked.
Now tick all three.

Then switch to the tab “Records” and open one of the two “… housing” pages (the indented records).
Our field appears in the input form with the label “Projects” as a lookup field:

In the area “Projects”, we had assigned a page to each project. Now we see this relation from the other side: The lookup field lists the linked projects.

Two perspectives of CMS:SELECT

1. relation

In the template page_projects, we used the command CMS:SELECT to fetch all projects of a page:

(CMS:SELECT list_projects
  relation=rel_projects
  sort="online_at DESC"
)

This is the first perspective of CMS:SELECT: It looks for records (projects) that are linked to the current record (the page) through the field rel_projects.

The current record is the one whose data is available at the moment and can be output with CMS:TEXT, for example. In our case, it is the record called up through the URL.

In the result template of CMS:SELECT, the current record changes with every pass: Between (CMS:RESULT_START) and (CMS:RESULT_END), the data of the hit currently being output is available.

2. filter

The second perspective of CMS:SELECT: searching for records that are linked to a particular record.
So we can also write the command above like this:

(CMS:SELECT list_projects
  filter[area]=projects
  filter[rel1_pages]=$cms[record_id]
  sort="online_at DESC"
)

The parameter filter narrows down the result set. Two filters apply here: The command fetches records that …

are located in the content area projects and
are linked to the record $cms[record_id] (only relations stored in the field rel1_pages are taken into account).

$cms always contains the data of the current record, so $cms[record_id] contains the number of the current record.

Instead of filter[rel1_pages], you can also write filter[rel1_pages.record_id] – after the dot comes the field in the target area that is searched.

You can find the record number record_id in the detail view of a record, in the tab “Meta data”.
Often, however, it is more practical to use a different field of the linked record as the criterion, such as title:

(CMS:SELECT ...
  filter[area]=projects
  filter[rel1_pages.title]=private*
  ...
)

This command fetches all projects linked to the page “Private housing” (upper and lower case do not matter).