Table view structure
Every table view is built from the same few parts: a selection of rows, a set of columns, and optional attributes that tune how both behave. This page goes through those parts one by one, from the row selection and the table-wide attributes to the anatomy of a column, and finishes with hierarchical table views, the variant that renders its rows as a collapsible tree.
A TableView is a SysML view definition, meaning expose / filter clauses
select which elements appear as rows, with ContentView attributes giving additional control over which elements
are included.
Table attributes
These attributes are inherited from TableView and affect the entire table:
Attribute |
Description |
|---|---|
|
Maximum height of each row in pixels. Content exceeding this height is clipped and shown in a tooltip on hover. |
|
Persisted global search-bar filter, applied across all columns. Typically not
authored by hand: typing in the search bar and saving view changes writes it
here. Per-column filter text is persisted separately, in each column’s
|
|
Reference list that overrides the visual column order without reordering the
SysML source. Drag-and-drop reordering and the Shown columns
dropdown in the UI update this attribute when view changes are saved. Columns
omitted from |
An example of how these features can be set for a table:
view myTable : TVD::TableView {
expose ExampleModel::**;
filter hastype SysML::RequirementUsage;
// Rows taller than 60 px are clipped; the full content moves to a hover tooltip
attribute :>> maxRowHeight = 60;
// Search-bar filter applied across all columns, as saved by Save View Changes
attribute :>> globalFilter = "drone";
// Visual column order: Description renders first; Name is omitted, so it is hidden
:>> columnOrder = (Description, ID);
view ID :> columnViews {
attribute :>> featureRepresentation :> ColRep::declaredShortName;
}
view Name :> columnViews {
attribute :>> featureRepresentation :> ColRep::declaredName;
}
view Description :> columnViews {
attribute :>> featureRepresentation :> ColRep::documentation;
}
}
Column views
columnViews is a child view of TableView. Each view usage that subsets it
becomes one column in the rendered table. The name of the column is the name of the
child view: view ID and view Description produce headers ID and Description.
By default, columns appear in the order their child views are declared in the SysML
source, though this order can be overridden through columnOrder or by drag-and-drop in the UI.
A column is defined by two independent halves: a navigation chain that selects which
element each cell is about, and a representation that selects what aspect of that
element to render. The chain is written into a column’s columnFeature feature.
A chain is a collection of navigation steps which are navigation functions that jump
from one element to one or more elements (e.g. the Owner function navigates from an
element to its owner).
baseViewElement
A navigation chain starts from baseViewElement, the default feature a cell
represents: a reference usage standing for the row’s element, whatever survived the
expose / filter clauses and the ContentView attributes. Navigation is therefore relative to what
was exposed and filtered to the view. The snippet below navigates from each row element
to its owner:
:>> columnFeature = Owner(baseViewElement);
Representations
The representation is written using a column’s featureRepresentation attribute. Representation
values come from the SysideViews::Representation enumeration. The snippet below
displays the declared name of the Owner of the row:
:>> columnFeature = Owner(baseViewElement);
attribute :>> featureRepresentation :> ColRep::declaredName;
Warning
The two redefinitions are written differently on purpose. featureRepresentation
is an attribute, but columnFeature is a plain feature, so its redefinition stays
bare: :>> columnFeature = …. Redefining it with a usage keyword, as in
attribute :>> columnFeature = …, changes the feature’s type and breaks the
column.
Column features
Each column contains the following features:
Feature |
Description |
|---|---|
|
Which element each cell is about: a navigation chain applied to every row. Unless set, the cell is
about |
|
What aspect of the chain’s target to render; the qualified name unless set. The full catalogue of values is in Representations. |
|
Shown greyed out when the chain reached its target but the representation holds no value there (for example, an attribute that is declared but not set). Such a cell stays editable when the representation is writable; see Cell outcomes. |
|
Shown when the chain never resolved to an element, for example a |
|
Initial column width in pixels. Resizing in the UI updates this attribute when view changes are saved. |
|
Persisted filter text for this column. Typically not authored by hand: filtering the column and saving view changes writes it here. |
An example of how these features can be set for a column:
view Priority :> columnViews {
// WHICH element the cell is about: navigate from the row element
// to its attribute named "priority"
:>> columnFeature = NamedUsage(baseViewElement, "priority",
UsageKind::attributeUsage);
// WHAT aspect of that element to render: its value
attribute :>> featureRepresentation :> ColRep::featureValue;
// Greyed-out fallback when "priority" is declared but has no value
attribute :>> defaultValue = "(unset)";
// Read-only fallback when the row has no "priority" attribute at all
attribute :>> notApplicableValue = "no priority";
// Initial width in pixels; resizing in the UI updates it on save
attribute :>> columnWidth = 120;
// Per-column filter text, as saved by Save View Changes
attribute :>> columnFilter = "high";
}
Hierarchical table views
A hierarchical table view is a specialisation of the regular table view that renders
model elements in a tree structure, reflecting parent–child relationships in the model.
It is typed by HierarchicalTableView instead of TableView, but authoring is
mostly identical to a flat table view: the same columns, navigation chains, and representations all apply.
Hierarchical table views are built on the Definition-Usage pattern: definitions carry the row data, and the nesting
of usages typed by them defines the tree. HierarchicalTableView bakes in the
mechanics this needs. It fixes exposeFeaturesAndHeritage = true and filters rows to
istype SysML::Definition, so only definitions appear as rows and neither setting
needs to be written explicitly.
The view must expose exactly one root Definition: the tree hangs off that single
root, which itself is not a row. A view whose expose / filter resolves to zero
or several definitions reports an error instead of rendering.
Hierarchical tables add one table attribute,
defaultCollapse: when true (the default), all rows are collapsed on first load,
and users expand individual rows interactively. Set it to false to start with the
tree fully expanded.
The tree column
Visually the hierarchy is represented in the first column: its cells are indented by
depth and hold the expand/collapse control. It is a view usage named hierarchicalColumn,
present in every hierarchical table, with declaredName as its default
representation. It differs from other columns in three ways:
It is always the first column and columnOrder cannot move another column ahead of it
It cannot be hidden through the UI
Its chain may not contain a Fan step (a specific navigation step type)
Here is an example snippet of how a hierarchical table could look like. Note how the
hierarchicalColumn is redefined rather than subset:
view myTable : TVD::HierarchicalTableView {
expose ExampleRequirement;
filter hastype SysML::RequirementDefinition;
view ID :>> hierarchicalColumn {
attribute :>> featureRepresentation :> ColRep::declaredShortName;
}
view Name :> columnViews {
attribute :>> featureRepresentation :> ColRep::declaredName;
}
view Description :> columnViews {
attribute :>> featureRepresentation :> ColRep::documentation;
}
}