Specifying References for Non-Hierarchical Representations

Dynamic View Services > Specifying Dynamic View Types > References > Specifying References for Non-Hierarchical Representations

The following code sample defines the specification of the CompanyMatrix view type as described in the presentation of the Company example. It relies on a matrix representation model that contains the representation classes (bridge classes) MatrixR, ColumnR, RowR and CellR. Each ColumnR and RowR object must reference its owning Matrix object, and a CellR object must reference its ColumnR and RowR objects.

Example

view CompanyMatrix:

subscribe origin Company:

represent Matrix matrix:

string title=identifier;

propagate projects;

propagate departments;

subscribe Department:

propagate employees;

subscribe Employee:

represent RowR row:

Ref<Matrix> owner=department.company->matrix;

string header=name;

propagate contributions;

subscribe Project:

represent ColumnR column:

Ref<Matrix> owner=view.origin->matrix;

string header=ident;

subscribe Contribution:

represent CellR cell:

Ref<RowR> row=employee->row;

Ref<ColumnR> column=project->column;

string value=nbMonths;

The notification path defined in the view type CompanyMatrix starts from a Company object and propagates to the relations projects and departments.

1. Each Project object that is a target of the projects relation is represented by a column in the matrix. This column has an owner attribute that must reference the owning matrix. However, there is no unary relation from Project to Company. The inverted relation Project::companies, is an n-ary relation because several companies may use —or contribute to— the same project. For a column to reference its matrix, the owner column attribute is specified with the following path expression:

view.origin->matrix

This path means: “The table associated with the main origin of the view”. It uses two implicit relations:

The relation view, which is a non-editable unary relation, is implicitly declared for each runtime type within the scope of a dynamic view type. Its target is the view instance itself.

The relation origin, which is also a non-editable unary relation, is implicitly declared on the dynamic view type and is considered a runtime server type.
The target of the origin relation is the view main origin (see the function IlsMvView::getMainOrigin described in the Reference Manual).

Using the view.origin path to establish a reference relies on the fact that there is only one matrix represented in each CompanyMatrix view. The section References and n-m Relations, presents a more general approach.

2. Each Department object that is a target of the departments relation in turn propagates notification to the relation employees. For each employee reached, a row is created in the matrix. It references its matrix through the attribute owner whose value is the following transitive path:

Ref<Matrix> owner=department.company->matrix;

3. Moreover, notification is propagated through the inverted n-ary relation contributions. Each notified Contribution object is represented by a Cell object. This cell has two attributes, row and column, to reference the RowR and ColumnR objects it is related to.

Notes:

1. The reference for the column attribute uses the inverted relation project while the reference for the row attribute uses the direct relation employee.

2. Because of the propagation order, rows and columns are always created before cells.

Version 6.3