Diagram - Domain Notation
Choose a semantic model and install its authoring module alongside the generic Diagram canvas.
Use a notation when a drawing needs domain rules: a sequence flow must stay in
its BPMN scope, a relationship must reference actual model members, or a copied
graph must retain its semantic dependencies. The saved Diagram model remains
the only graph. Domain data lives in versioned extensions.primeuiNotation
envelopes on its records.
#Choose a model
| Model | What you author | Start here |
|---|---|---|
| BPMN | Descriptive processes, activities, events, gateways, participants, messages, data and visual categories | BPMN basics |
| UML Class | Classifiers, rows and typed relationships | Class modeling |
| ER | Entities, fields, keys and relationships | ER modeling |
| Activity | Actions, pins, flows, partitions and exception handlers | Activity modeling |
| Sequence | Lifelines, occurrences, messages, activations and fragments | Sequence modeling |
These are authoring profiles. Scripts, conditions, message names, timing and call references describe a model; Diagram does not execute a process or deliver messages. Read each profile before importing a model from another tool.
#Install the module when creating the store
The optional module supplies validation and semantic copy/history rules. Configure
notationModules in createDiagramStore(model, options). At most 16 modules with distinct nonempty IDs are accepted. Modules stay fixed
for that store lifetime; mounting an inspector does not install one.
Activity has separate advanced profiles for events, structured ownership, partitions and handlers. Sequence has separate fragment examples for operands, nesting and reuse.
The copied inspector is an editable form for the public notation model. The legacy runtime inspector is a compatibility surface with its own template; its presence does not mean you copied the current form. Use the exact optional entry shown in the UI-parts reference.
Pass the notation module in createDiagramStore(model, { notationModules }). The module validates semantic records and supplies copy, paste and history rules. Modules stay fixed for the store lifetime. Mounting a semantic root or inspector does not install one.
| Public entry | Semantic component | Copied inspector |
|---|---|---|
@primeui/vue-diagram/bpmn | DiagramBpmnRoot | DiagramBpmnInspectorUI |
@primeui/vue-diagram/uml | DiagramUmlRoot | DiagramUmlInspectorUI |
@primeui/vue-diagram/er | DiagramErRoot | DiagramErInspectorUI |
@primeui/vue-diagram/activity | DiagramActivityRoot | DiagramActivityInspectorUI |
@primeui/vue-diagram/sequence | DiagramSequenceRoot | DiagramSequenceInspectorUI |
Each semantic component belongs inside Diagram.Root. The copied inspector belongs inside its semantic component. Its local import comes from the corresponding copied UI folder, such as ./components/primeui/diagram/bpmn. It follows the current selection and creates its own inspector host. UML and ER use native compartments and row ports. BPMN, Activity and Sequence examples register their symbol libraries on the generic root.
For a custom inspector, nest the matching host, such as DiagramBpmnInspectorHost, under the semantic root. Its optional entityId selects a record explicitly; omission follows the first selected record. Call useDiagramBpmnInspector() in a child of that host. The returned DiagramBpmnInspectorModel contains readonly refs and bound actions. Use setDraft, setItemId, setIoId and the relevant semantic actions instead of assigning snapshot fields. The other notation entries provide the matching host, composable and model type.
#Keep model, draft and status ownership clear
Factories construct records. Typed editors propose changes through the existing session/store. Installed validators check initial creation and subsequent writes, including controlled synchronization and history. A rejected edit has diagnostics and leaves the saved model unchanged. An incomplete but structurally valid model can commit and retain completeness warnings. A warning count is not an error count.
Copied forms hold drafts separately from saved records. Explicit save actions submit typed changes. Draft reconciliation follows selected entities, catalog/IO choices, model changes and status changes; a draft is not a persistence buffer. Read-only and current content/structure/transform permissions still apply. Undo and Redo recheck current permissions rather than bypassing the editor.
A pending proposal remains owned by the host/store or connection approval path.
Do not label pending as a saved change. Semantic roots track settlement and cancel
stale ownership when their store or session changes. Applications own supplied
store/registry disposal; each demo releases subscriptions and disposes its resources.
Factories construct records; they do not authorize or commit edits. Typed editors submit changes through the existing store and session. The semantic component exposes run(action) for operations on its editor. Its showDefaultStatus prop defaults to true; disable it when your own child controls render feedback.
Installed validators check initial creation and subsequent writes, including history and controlled synchronization. Rejected edits leave the saved graph unchanged. An incomplete but structurally valid graph can commit with completeness warnings. A warning is not a rejected transaction, and pending is not a completed save.
Copied forms keep drafts apart from saved records. Selection changes, model changes and available catalog choices reconcile those drafts. Explicit form actions submit the saved changes. Read-only policy and current content, structure and transform permissions still apply. Undo and Redo recheck current permissions.
Read live root state with useDiagramContext() in a small child beneath Diagram.Root. Use context.model.value, context.interaction.value and context.session.value in setup; destructured refs unwrap in templates. Do not gate these children on a root template ref or mutate readonly snapshots. Keep a caller-created store and symbol registry alive while the root uses them, and dispose them when replaced or unmounted.
#Recover unsupported envelopes
A store without the owning module can retain opaque notation payloads for recovery.
That does not validate them as the active domain model. Copying without a module
marks the payload unresolved; identifiers cannot silently become live references
in another graph. Active BPMN rejects unsupported versions and unresolved payloads.
Repair or explicitly clear unsupported content before creating an active store.
Keep a recoverable native model instead of discarding unknown data.
DiagramNotationEnvelope contains module, version, JSON data and optional unresolved. Built-in modules handle dependency remapping and validation. Prefer them to custom remappers when they match the notation. Preparation and validation hooks must not write to the store.
DiagramNotationEnvelope has module, version, JSON data and optional
unresolved. The runtime-only DiagramNotationModule contract has an id, pure
synchronous validate and remap, with optional historyPermissions, prepareCut
and preparePaste. Paste preparation can return a page envelope, derived label
texts and inert remap data; graph and metadata commit together. These hooks do not
permit store writes inside preparation or validation. Prefer built-in modules to
an application remapper when one matches the model.
See BPMN graph reuse for dependency capture and rejection, native save/load for whole models, and the BPMN XML guide for file exchange.