Cell representations

In a table view in the Syside VS Code Extension, each column shows one aspect of the element its navigation chain reaches, such as its name, its documentation or its value. That aspect is the column’s representation, and it is the same for every cell in the column.

A column sets its representation in its featureRepresentation attribute, using a value from the SysideViews::Representation enumeration (short name ColRep):

Representation	Description	Writable
`ColRep::declaredName`	The element name exactly as written in the source model.	✗
`ColRep::declaredShortName`	The short name as written in the source model (the `<…>` form), for example a requirement ID such as `<REQ-001>`.	✗
`ColRep::name`	The semantically resolved name of the element (may differ from `declaredName` after redefinition).	✗
`ColRep::shortName`	The semantically resolved short name of the element.	✗
`ColRep::qualifiedName`	The fully qualified name of the element, including all enclosing namespaces. The default.	✗
`ColRep::documentation`	All documentation blocks on the element, concatenated in declaration order.	✗
`ColRep::direction`	The declared direction of a feature (`in`, `out`, `inout`).	✗
`ColRep::featureValue`	The value of the target element itself. The chain must land on a feature.	✓
`ColRep::specificDocumentation`	A single named or unnamed documentation block, selected by `documentationName`. See Representation parameters.	✓
`ColRep::'language'`	The language-specific textual body of the target element, such as the `language "English"` body of a constraint. Selected by `languageName`. See Representation parameters.	✓

Any representation can follow any chain: the same ColRep::name column renders the row element, its owner, or each fanned-out port, depending only on columnFeature.

Representation parameters

Two representations take a parameter that selects which value to show:

Parameter	Representation	What it represents
`documentationName`	`specificDocumentation`	The name of the documentation block to show. `""` selects the unnamed documentation body. Default: `""`.
`languageName`	`'language'`	The language of the textual body to show. An empty `languageName` matches nothing: every cell shows the column’s `defaultValue`, read-only. Default: `"English"`.

Because featureRepresentation subsets a ColRep member, the parameter is set by redefining it inside the block:

view Rationale :> columnViews {
    attribute :>> featureRepresentation :> ColRep::specificDocumentation {
        attribute :>> documentationName = "rationale";
    }
}

Cell outcomes

Every cell ends up in one of four states, which decide what it shows and whether it can be edited. Rows, columns and cells explains where they come from.

Outcome	Shown	Editable
Value found	The rendered value: the chain reached an element and the representation found a value on it.	Per the editability rules.
Applicable, no value	The column’s `defaultValue`, grayed out. The chain reached its element, but the representation holds nothing there. A `List` step that found nothing also shows it, read-only.	Yes, when the representation is writable.
Not applicable	The column’s `notApplicableValue`. The chain never resolved to an element: a step rejected its input (such as `Subject` on a part) or ran dry partway, including a `Fan` step that found nothing. Hovering the cell explains which step rejected it.	Never.
Truncated	The first element found, with a warning note: a `First` step found more than one.	Never.

Editable representations

A cell can be edited inline when two things hold: the representation is writable (featureValue, specificDocumentation, or 'language'), and the column’s chain resolved to exactly one target for that row. Cells in List columns are always read-only, as are not-applicable and truncated cells.

specificDocumentation and 'language' cells edit as free text. featureValue is writable when the target is an attribute usage. For other feature kinds, such as parts and ports, the value is read-only. For a writable attribute, the column picks an editor based on the attribute’s declared type. If the type is not explicit, it is inferred from existing values. The following types are supported:

Attribute type	Editor behavior
Enumeration	Single-select dropdown listing the literals of the attribute’s declared enumeration.
Enumeration (multiplicity upper bound above 1)	Multi-select dropdown with the same literal list. See Single-select versus multi-select dropdowns.
Boolean	Dropdown with `true` and `false` options.
String	Free-text input.
Numeric	Numeric input.

Quantities from the SI standard library are read-only and display without their unit.

A new featureValue is bound with default in a definition and with = in a usage. An existing binding keeps its keyword.

Missing attributes

A featureValue column can also create an attribute that does not exist yet. This works when the column’s last step looks up an attribute by name:

:>> columnFeature = NamedUsage(
    baseViewElement, "priority", NameType::name, UsageKind::attributeUsage
);

For a row whose element has no priority attribute, the cell shows defaultValue and can still be edited. Saving a value adds a priority attribute to the element the step started from, which is the row’s element in this one-step chain. With NameType::shortName, the new attribute gets priority as its short name instead.

The cell stays read-only, and nothing is created, when:

An earlier step found no element.
A First step found more than one element.
An earlier step crossed an inheritance boundary (see Inherited values).

Single-select versus multi-select dropdowns

Whether an enumeration column renders a single-select or a multi-select dropdown is decided by the attribute declaration in the model, not by the view. The attribute’s declared multiplicity is what matters. With the default multiplicity of one, the cell edits as a single-select dropdown. Declare an upper bound above one, or an unbounded multiplicity such as [0..*], and the same column renders a multi-select dropdown:

enum def Category { safety; performance; usability; }

requirement def MaxAltitude {
    attribute mainCategory : Category;        // single-select dropdown
    attribute categories : Category [0..*];   // multi-select dropdown
}

Selected literals from a multi-select cell are written back as a collection value, for example (Category::safety, Category::usability). If the attribute declares no multiplicity of its own, the multiplicity is inherited from the attribute it redefines.

Inherited values

Navigating usage features (the Usage and RequirementConstraints families and NamedUsage) includes inherited features, and inherited cells are marked as such in the UI. Editing rules differ by representation:

A featureValue cell whose final step landed on an inherited attribute stays editable. Saving writes a redefinition of the attribute onto the element the final step started from, the row’s element for a one-step chain, and leaves the base untouched. If the base bound the value with = rather than default, the cell is read-only.
A 'language' or specificDocumentation cell is read-only whenever its chain crossed an inheritance boundary anywhere, and so is a featureValue cell whose chain crossed one before the final step. To make such a cell editable, redefine the constraint or documentation in the row’s element.
Steps that move to another element, such as HeritageFirst, DefinitionsFirst and Owner, do not count as crossing inheritance. This chain edits the base element directly:
```
NamedUsage(HeritageFirst(baseViewElement), "x", NameType::name)
```

What an edit writes explains why the rules differ.