Use grid views
This page covers the grid view workflow inside the Modeler editor: open a view from the SysMLv2 Views panel or from its source definition, then filter and sort rows, edit cells inline, create requirements, manage traceability links, and export to CSV. To define the views themselves, see Configure table views and Configure matrix views.
SysMLv2 Views panel
All available views in the current workspace are listed in the SysMLv2 Views panel
in VS Code’s Explorer sidebar titled SysMLv2 Views (labs). Once a view is written in
a .sysml file, it appears here automatically.
Click the view name to open it as a panel
Click the pencil icon on the right to jump to the SysML source definition
When opening a workspace for the first time, the SysMLv2 Views panel offers to add the
SysideViews.sysml library file to the workspace directory. This is required for any
grid view definitions to work; accepting the prompt places the library automatically.
Warning
There is a known bug where renaming the SysideViews.sysml file after it has been
added to a workspace can cause the extension to stop resolving the library.
Open from the Editor
A view can also be opened directly from its source definition: right-click inside a
.sysml (or .kerml) editor and choose Visualize view (labs) →
As table to open the view at the cursor position as a populated table or
matrix. Choosing As diagram renders the same view as a diagram instead.
Save View Changes
Some grid view interactions write to the source .sysml file immediately (such as
inline cell edits). Others (resizing, reordering, or hiding columns, filtering rows)
are staged in the UI and committed by clicking Save View Changes at the top of the
view. Both tables and matrices use this pattern.
Working with tables
In a table view, rows are model elements and columns are their aspects: names, documentation, attribute values, constraints. The sections below walk through what an open table can do: find rows with filters and sorting, shape the layout by showing, hiding, and reordering columns, jump to the SysML source, edit values inline, create new requirements without leaving the table, and fan rows out into finer-grained sub-rows.
Filter rows
Type in the search bar at the top of the table to filter rows across all columns simultaneously. Column-level filters live in a separate row of filter boxes: the Column filters toolbar toggle, off by default, shows and hides them, and a Clear column filters button appears once any of them holds text.
Filters are staged as view changes. Clicking Save View Changes at the top of the view writes the filter text into the view definition, so the filtered state is 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; × removes an entry, and once the stack holds more than one entry, arrows reorder their priorities.
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; the resulting column order is saved into the view definition, with hidden columns omitted.
Inline editing
Cells with an editable representation can be edited directly in the table or via the right-click context menu (View Row Details). Changes are written back to the model on save confirmation.
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 model; 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:
The image reference supports the following patterns:
Pattern |
Resolution |
|---|---|
|
Relative path, resolved against the directory of the |
|
Absolute filesystem path. |
|
Absolute |
|
Relative |
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.
Web URLs (https:// or http://) are not supported.
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
Right-click a row and choose Add Requirement to create a new requirement next to it. The creation dialog collects the new element’s names and relationships, previews the exact SysML that will be written, and appends it to the model file on confirmation. The new row appears immediately if it satisfies the view’s filters.
In flat table views the new element is created next to the clicked row: the namespace comes pre-filled from the row element’s owner. The menu entry is disabled when the view’s filters do not admit requirements, and whenever the model cannot currently be written to: it has errors, source files hold unsaved edits, or another write is still in flight.
Create rows in a hierarchical table
A hierarchical table row is a definition reached through a usage typed by it, so creating one means creating both halves in the right places. Right-clicking a row offers two entries that do exactly that, opening the creation dialog with both namespaces filled in from the clicked row:
Add Sibling Requirement places the new row alongside the clicked one. The usage is created in the namespace of the row that was right-clicked
Add Sub-Requirement places the new row underneath the clicked one. The usage is created inside the clicked row’s definition, which is what makes it a child in the tree
Both entries put the new definition in the namespace of the clicked row’s definition. Each pre-filled field carries an ⓘ hint naming the namespace it was locked to and why.
Add Sibling Requirement works from any row, whatever kind of usage the row was reached through: what fixes the new element’s position is the place, not the kind of the element clicked. Add Sub-Requirement is greyed out on a definition that appears more than once in the hierarchy, since the new usage would land under every occurrence.
If a namespace cannot be mirrored from the clicked row, that field falls back to the full list and a notice points out that the unlocked fields need to be picked by hand.
Advanced table structure
Columns are not limited to one cell per row. A table can fan a row out into several sub-rows, one per element a column found: for example one sub-row per port of each part. The cells of the other columns then span the run of sub-rows their row produced, so the parent stays readable alongside its details (see Fanning out rows).
per port, with the part-level cells spanning their sub-rows.
Working with matrices
A matrix view marks the relationships between two sets of elements, one on each axis. Reading it is the everyday use; an editable matrix goes further and turns the grid into a traceability workbench, where clicking cells creates and removes the relationships themselves.
Add and remove links
In an editable matrix, right-click an empty
cell and choose Add Traceability to add a new relationship of the
preset’s type, or right-click an existing mark and choose
Remove Traceability to remove it. Changes are written to the source
.sysml file immediately.
The direction of a created relationship follows the matrix’s configured direction. In an undirected matrix (the default), Add Traceability opens a submenu for choosing 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.