Reference and Propagation Order

Dynamic View Services > Specifying Dynamic View Types > References > Reference and Propagation Order

In the code sample below, the specification is slightly modified so that the contributions are notified through the propagation of the relation Project::contributions rather than through the relation Employee:contributions.

Example

view CompanyMatrix:

subscribe origin Company:

represent Matrix matrix:

string title=identifier;

propagate departments;

propagate projects;

subscribe Department:

propagate employees;

subscribe Employee:

represent RowR row:

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

string header=name;

subscribe Project:

represent ColumnR column:

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

string header=ident;

propagate contributions;

subscribe Contribution:

represent CellR cell:

mandatory Ref<RowR> row=employee->row;

Ref<ColumnR> column=project->column;

string value=nbMonths;

This change implies two other modifications:

Notification is first propagated to the relation departments of the Company object, and only then is it propagated to the relation projects. This is to ensure that rows are created before cells.

The reference row to the cell representation is specified as mandatory:

represent CellR cell:

mandatory Ref<RowR> row=employee->row;

When a mandatory reference is null, the representation that contains the attribute is not created. This is the case, for instance, if the target of the relation employees is null or if the target is an employee that does not belong to the company. (Remember that a project may receive contributions from different companies.)

This example illustrates how propagation order is significant in a dynamic view type specification. Even the relative order between propagation and representation directives can be meaningful, and it is sometimes necessary to propagate notification through a number of relations of an object before the object can be represented.

Version 6.3