Use Grid Views

This page covers the in-editor workflow features for grid views. The SysMLv2 Views panel and Save View Changes are shared workflows introduced in the Modeler essentials. For authoring, see Foundations, Configure Table Views, and Configure Matrix Views.

Working with Tables

Workflow features specific to table views.

Filter Rows

Type in the search bar at the top of the table to filter rows. There is a global filter that applies to all columns simultaneously, and a column-level filter that applies to the rows in that column.

Filters are staged as view changes. Clicking Save View Changes writes them into the view definition: the global filter into the table’s globalFilter attribute, each column filter into that column’s columnFilter attribute. The filtered state is then restored the next time the view is opened.

Hierarchical table views add an Include parents toggle next to the search bar, off by default. While a filter is active and the toggle is off, only rows whose own content matches are shown, as a flat list. Turning the toggle on keeps the ancestor rows of every match, preserving the tree context. When no filter is active the toggle has no effect.

Sort Rows

Click a column header to sort by that column; click again to reverse the direction. For multi-column sorting, use the + Add sort button in the toolbar to build a sort stack. Each entry appears as a chip with a priority number and a direction indicator. Clicking the indicator cycles it through ascending, descending, and removed; arrows change the entry’s priority, and × removes it.

Sorting is a display-side setting only; it is not written to the view definition.

Show and Hide Columns

The Shown columns dropdown in the toolbar toggles individual columns on and off; its label shows how many columns are currently hidden. Like drag-and-drop column reordering, visibility changes are staged and committed with Save View Changes. They are written to the table’s columnOrder attribute: the visible columns in their displayed order, with a hidden column simply omitted (see Table Attributes).

Source Navigation

All column types support source navigation via the right-click context menu:

• Go to Row Element jumps to the element’s declaration in the .sysml file

• Go to Cell Element jumps to the source of the specific cell value (e.g. the attribute declaration). When a cell has multiple source locations, a submenu lists each one

Inline Editing

Cells in editable column types can be edited directly in the table or via the right-click context menu (View Row Details). Changes are written back to the model immediately.

Row Details

Right-clicking any row opens a context menu with a View Row Details action that opens a modal showing all columns for that row in a scrollable vertical layout. Editable fields can be edited directly inside the modal; changes are saved on confirm or discarded on cancel.

The Row Details modal renders documentation values as Markdown, so diagrams and screenshots can be embedded directly in requirement documentation using standard Markdown image notation:

![Alt text](images/diagram.png)

The image reference supports the following patterns:

Pattern	Resolution
images/diagram.png	Relative path, resolved against the directory of the .sysml file that declares the row element.
/abs/path/diagram.png	Absolute filesystem path.
file:///abs/path/diagram.png	Absolute file:// URI. The file://localhost/abs/path form works as well.
file://./images/diagram.png	Relative file:// URI, resolved against the .sysml file’s directory. The bare form file://images/diagram.png works as well.
https://example.com/diagram.png	Web URL, loaded directly. http:// works as well.
data:image/png;base64,...	Inline data URI, rendered directly.

Local files must be inside the opened workspace. A file that is missing or outside the workspace renders as an inline Image not found annotation instead of a broken image.

Note

View Row Details is disabled while there are unsaved cell changes in the main table. Save or discard the pending changes first.

View System Hierarchy

A hierarchical table view renders model elements in a collapsible tree, reflecting parent–child usage nesting. Expand or collapse individual rows by clicking the toggle in the first (hierarchy) column.

Create Requirements

When a table view is open, click the + Add Requirement button in the top right corner to open the creation dialog. Configure the fields and confirm to append the new element directly to the model file.

Definition or Usage

Select the kind of element to create:

• Definition, a type declaration (requirement def), placed inside a package

• Usage, an instance (requirement), placed inside a type such as a requirement definition or part definition

Switching between the two modes resets the namespace and relationship fields.

Namespace

The namespace dropdown lists model elements already exposed by the current table view. In Definition mode it lists packages; in Usage mode it lists type definitions that own at least one exposed element. If the selected namespace lies outside the view’s expose / filter scope, a warning is shown. Creation can still proceed, but the new row will not appear in the table until the view or filter is updated.

Short Name and Name

At least one of Short Name or Name must be provided. Both are independent; setting both gives the element a <short_name> and a 'declared name'.

Specializes / Typed By

An optional dropdown links the new element to an existing RequirementDefinition:

• In Definition mode it is labelled Specializes (:>) and adds a Subclassification relationship to the generated definition

• In Usage mode it is labelled Typed By (:) and adds a FeatureTyping relationship to the generated usage

Metadata Tags

An optional list of metadata annotations for the new element. Click + Add Tag, pick a metadata definition from the model in the dropdown, and choose how the tag is applied:

• Prefix annotates the declaration: #TagName requirement def ...

• Owned Tag adds the metadata as an owned member of the element’s body: @TagName;

Multiple tags can be combined on one element.

SysML Preview

A live syntax preview below the name fields shows the exact SysML that will be appended to the model file, updating as fields change.

After confirming, the extension writes the change and refreshes all open table panels. The new row appears immediately if it satisfies the view’s filter expression.

Create Next to a Row

In flat table views the dialog can also be opened by right-clicking a row and choosing Add Requirement. This flow creates the new element next to the clicked row: the Namespace field is locked to the row element’s owner, and the Definition / Usage choice is preselected when only one of the two passes the view’s filters. The menu entry is disabled when the view’s filter clauses do not admit requirements, or while the model has errors.

Note

Requirement creation is currently designed for flat tables. Hierarchical table views do not offer the row-level menu entry: a hierarchical row requires both a definition and a usage typed by it, which the single-element dialog cannot express. Hierarchical table support is planned for a future release.

Working with Matrices

Workflow features specific to matrix views.

Add and Remove Links

In an editable matrix, click an empty cell to add a new relationship of the preset’s type, or click an existing mark to remove it. Changes are written to the source .sysml file immediately.

The direction of a created relationship follows the direction attribute on cellView. When direction is Dir::undirected, the user is prompted to choose the direction at creation time.

Relationship creation can be disabled for a given row or column element; see Disabled Cells.

Export to CSV

Both table and matrix views have an Export as CSV button in the top-right corner of the panel. Clicking it opens a save dialog; once the export completes, a notification with an Open action points at the written file.

In table views the button is disabled while there are unsaved cell changes. Save or discard the pending changes first.

Views can also be exported without opening the editor, for example in a CI pipeline, using the syside CLI. See syside table export.