Diagram - Activity Basics

#Usage

This component accepts an initial Activity model and its page ID. Supply the records shown in a demo below. Copy the preset inspector files to the local import path and follow Setup for application styles and licensing.

<script setup lang="ts">
import { onBeforeUnmount } from 'vue';
import { Diagram, createDiagramStore, DiagramSymbolRegistry, type DiagramModel } from '@primeui/vue-diagram';
import { DiagramActivityRoot, createDiagramActivityModule, createDiagramActivitySymbols } from '@primeui/vue-diagram/activity';
import { DiagramActivityInspectorUI } from './components/primeui/diagram/activity';

const props = defineProps<{ model: DiagramModel; pageId: string }>();
const created = createDiagramStore(props.model, { notationModules: [createDiagramActivityModule()] });
if (!created.ok) throw new Error(created.diagnostics.map((item) => item.message).join('; '));
const store = created.value;

const symbols = new DiagramSymbolRegistry();
for (const symbol of createDiagramActivitySymbols()) symbols.register(symbol);

onBeforeUnmount(() => {
    symbols.dispose();
    store.dispose();
});
</script>

<template>
    <Diagram.Root :store="store" :page-id="pageId" :symbols="symbols">
        <DiagramActivityRoot>
            <Diagram.Viewport label="Activity model" auto-fit style="height: 30rem" />
            <DiagramActivityInspectorUI />
        </DiagramActivityRoot>
    </Diagram.Root>
</template>

The model is read once during setup. For file loading or Reset, replace the store deliberately and dispose the previous caller-owned store. The root owns its session. The copied inspector follows selection and creates its own DiagramActivityInspectorHost; a custom form uses that host with useDiagramActivityInspector() in a child component. Its snapshots are readonly refs. Read .value in setup and use the documented actions to change drafts or selections. Mounting a form does not install the notation module.

An Activity describes actions and their relationships. Its page is the Activity identity; nodes and flows have explicit semantic owners. Diagram draws and validates this model without moving tokens or evaluating action, guard or datatype text.

#Start with a small Activity

Choose Focus review, then use Edit selected element to rename Review order. The Initial begins a ControlFlow path and Done is an Activity Final. Undo restores a saved edit in one step. Read only leaves selection, Fit and inspection available; Restart example restores the initial model in a fresh store with empty history.

Fixtures that need owned pins are built through the public editor, then opened from the finished snapshot so initial construction does not consume the user's Undo history. The application owns stores/registries and releases them when replaced or destroyed.

#Connect objects through ordered pins

Prepare order produces an Order object, which flows into Ship order's input pin. Choose Reorder outputs to change anchor spacing while retaining the connected pin and port identities. Remove spare output removes an unconnected pin. Try connected pin removal rejects; remove or reconnect that pin's flows first.

A semantic pin has its own node ID, ownerActionId, direction and independent physical portId. The owning action stores the ordered pin node IDs in pins. These are different identities. addPin changes ownership and geometry atomically; do not create a pin with a standalone create or ordinary reparent operation.

Ordinary input pins accept ObjectFlow, output pins originate it. ObjectFlow attaches to action pins rather than executable action bodies. Object nodes and control nodes can also be supported ObjectFlow endpoints. ControlFlow cannot attach to objects or pins. Optional pin connectionType tags use exact matching when both ends have tags; datatype/state text does not infer type compatibility. Optional nonnegative integer capacity counts graphical links, not UML token multiplicity.

#Author a guarded decision

Review feeds Ready? through its primary ControlFlow. The outgoing ready and else branches therefore remain ControlFlow. Add decision input creates one supplemental ObjectFlow from Stock with explicit decisionInput: true. Try second else rejects without replacing the saved guard. Select a branch and use the copied flow form to edit its inert name/guard or actual endpoints.

A Decision accepts at most one primary incoming and one explicit supplemental ObjectFlow. Its outgoing kinds agree with the primary incoming kind and with each other. Exactly trimmed else is reserved for a Decision outgoing guard; at most one outgoing edge may use it. Diagram does not evaluate a condition or choose a branch.

#Control profiles and incomplete authoring

Missing incoming/outgoing connections and insufficient Decision/Fork/Merge/Join branches produce completeness warnings where the unfinished graph is structurally valid. Empty action/object/pin names also warn. Illegal kinds, endpoint directions, scopes or identities reject; a warning does not bypass those constraints.

#Core data and editing reference

IDs begin with an alphanumeric and use only letters, numbers, _ . : -, up to 128 characters. Names are at most 128; datatype/state and guard text at most 256; connection tags at most 128. Omit unset optional properties. Unknown keys, unsupported versions or unresolved active payloads reject. Ordered input/output anchors need at least 18 local units between anchors and corners; enlarge the owner when adding pins. Existing pin owner/port identities cannot be rebound by a node description.

Typed edits, connection approval, controlled proposals and Undo/Redo all follow current editing permissions. Incomplete authoring may commit with warnings. A rejection preserves the graph; pending remains owned by its store or connection path. See Activity profiles for event actions, structured boundary ports, independent partitions, annotations and exception handlers.

#Related Docs

• Choose a Notation
• Supported Profiles
• API