@peter.prib/renderengine 0.2.5 → 0.2.7

package/src/datamodel.js

@@ -1,122 +1,132 @@
-// Copyright 2026 Jaroslav Peter Prib, Purveyor of Excellence
-/**
- * Data-modelling notation — deliberately its own file/OO module, same split
- * as src/archimate.js: keeps this domain's vocabulary (levels, notation
- * styles, cardinality) out of RenderEngine itself, queried through the
- * `DataModelNotation` registry rather than flat string-keyed maps.
- *
- * **Three levels, one entity.** A conceptual/logical/physical data model
- * isn't three unrelated diagrams — it's the same entities and relationships
- * shown at increasing fidelity. `dataModelDiagram` (see RenderEngine)
- * expresses that as ONE entity object carrying per-level detail
- * (`entity.logical.attributes`, `entity.physical.attributes`, ...) under a
- * shared `name`/`description` — the same "object" (level-agnostic identity)
- * vs "visual/detail" (this level's own presentation) split archimateDiagram
- * already draws between an element and its diagram — with `options.level`
- * picking which one's on screen. That's the cross-mapping: switching level
- * re-renders the SAME entities/relationships, not a second, separately
- * maintained diagram, so a conceptual entity, its logical attributes, and
- * its physical column types can never drift out of correspondence.
- *
- * **Three notations, one cardinality vocabulary.** A relationship's
- * cardinality at each end is stored once, as a UML-style multiplicity
- * string (`'0..1'|'1'|'0..*'|'*'|'1..*'`) — CARDINALITIES below — and each
- * `NotationStyle` renders it its own way: Chen turns the relationship
- * itself into a diamond-shaped node with a plain text label ('1'/'N') on
- * each connecting edge; Crow's Foot renders it as an arrowhead-style glyph
- * at the entity end (fork for "many", tick for "one", circle for
- * "optional" — see the `crowsfoot-*` markers in SVGRenderer.js); UML shows
- * the multiplicity string itself as a text label near that end
- * (`edge.sourceLabel`/`targetLabel`, a plain graphDiagram feature, not
- * data-model-specific). None of these are pixel-perfect renditions of the
- * real notations' full rule set (Chen's own attribute-oval convention,
- * every crow's-foot optionality combination, UML's aggregation/composition
- * diamonds) — they're a representative, genuinely-readable version of each,
- * the same calibration archimateDiagram's own icons use.
- */
-
-/** One data-modelling abstraction level. See DataModelNotation.levels(). */
-export class DataModelLevel {
-    constructor(name, description) {
-        this.name = name;
-        this.description = description;
-    }
-}
-
-/** The canonical cardinality vocabulary every NotationStyle renders
- *  differently — UML-style multiplicity strings, since they're the only one
- *  of the three notations expressive enough to BE the canonical form
- *  without losing information (Chen/Crow's Foot each collapse some of these
- *  distinctions on purpose). */
-const CARDINALITIES = new Set(['0..1', '1', '0..*', '*', '1..*']);
-
-function chenCardinalityLabel(cardinality) {
-    return cardinality === '1' || cardinality === '0..1' ? '1' : 'N';
-}
-
-const CROWSFOOT_ARROWHEADS = {
-    '1': 'crowsfoot-one',
-    '0..1': 'crowsfoot-one-optional',
-    '1..*': 'crowsfoot-many-mandatory',
-    '0..*': 'crowsfoot-many',
-    '*': 'crowsfoot-many',
-};
-
-/**
- * One drawing technique for entities/relationships — Chen, Crow's Foot, or
- * UML (class-diagram style). `entityShape` picks the graphDiagram node shape
- * (`'rect'` for a plain box, `'table'` for a header + attribute-rows card);
- * `relationshipAsNode` (Chen only) turns a relationship into its own
- * diamond-shaped node with two plain edges instead of one direct edge;
- * `cardinalityArrowhead`/`cardinalityLabel` (each `(cardinality) => value or
- * undefined`) pick how a relationship's own cardinality at one end renders
- * — at most one of the two is ever set for a given notation, the other
- * always returns undefined.
- */
-export class NotationStyle {
-    constructor(name, { entityShape, relationshipAsNode, cardinalityArrowhead, cardinalityLabel }) {
-        this.name = name;
-        this.entityShape = entityShape;
-        this.relationshipAsNode = relationshipAsNode;
-        this.cardinalityArrowhead = cardinalityArrowhead;
-        this.cardinalityLabel = cardinalityLabel;
-    }
-}
-
-const LEVELS = {
-    conceptual: new DataModelLevel('conceptual', 'Entities and their relationships only — no attributes, no keys, no types.'),
-    logical: new DataModelLevel('logical', 'Attributes and keys, still database-agnostic — no column types or engine specifics.'),
-    physical: new DataModelLevel('physical', 'Real column types, keys, and constraints as they exist in an actual database.'),
-};
-
-const NOTATIONS = {
-    chen: new NotationStyle('chen', {
-        entityShape: 'rect',
-        relationshipAsNode: true,
-        cardinalityArrowhead: () => undefined,
-        cardinalityLabel: chenCardinalityLabel,
-    }),
-    crowsfoot: new NotationStyle('crowsfoot', {
-        entityShape: 'table',
-        relationshipAsNode: false,
-        cardinalityArrowhead: (cardinality) => CROWSFOOT_ARROWHEADS[cardinality],
-        cardinalityLabel: () => undefined,
-    }),
-    uml: new NotationStyle('uml', {
-        entityShape: 'table',
-        relationshipAsNode: false,
-        cardinalityArrowhead: () => undefined,
-        cardinalityLabel: (cardinality) => cardinality,
-    }),
-};
-
-export const DataModelNotation = {
-    levels() { return Object.values(LEVELS); },
-    levelNames() { return Object.keys(LEVELS); },
-    level(name) { return LEVELS[name]; },
-    notations() { return Object.values(NOTATIONS); },
-    notationNames() { return Object.keys(NOTATIONS); },
-    notation(name) { return NOTATIONS[name] || NOTATIONS.crowsfoot; },
-    isCardinality(value) { return CARDINALITIES.has(value); },
-    cardinalities() { return [...CARDINALITIES]; },
-};
+// Copyright 2026 Jaroslav Peter Prib, Purveyor of Excellence
+/**
+ * Data-modelling notation — deliberately its own file/OO module, same split
+ * as src/archimate.js: keeps this domain's vocabulary (levels, notation
+ * styles, cardinality) out of RenderEngine itself, queried through the
+ * `DataModelNotation` registry rather than flat string-keyed maps.
+ *
+ * **Three levels, one entity.** A conceptual/logical/physical data model
+ * isn't three unrelated diagrams — it's the same entities and relationships
+ * shown at increasing fidelity. `dataModelDiagram` (see RenderEngine)
+ * expresses that as ONE entity object carrying per-level detail
+ * (`entity.logical.attributes`, `entity.physical.attributes`, ...) under a
+ * shared `name`/`description` — the same "object" (level-agnostic identity)
+ * vs "visual/detail" (this level's own presentation) split archimateDiagram
+ * already draws between an element and its diagram — with `options.level`
+ * picking which one's on screen. That's the cross-mapping: switching level
+ * re-renders the SAME entities/relationships, not a second, separately
+ * maintained diagram, so a conceptual entity, its logical attributes, and
+ * its physical column types can never drift out of correspondence.
+ *
+ * **Three notations, one cardinality vocabulary.** A relationship's
+ * cardinality at each end is stored once, as a UML-style multiplicity
+ * string (`'0..1'|'1'|'0..*'|'*'|'1..*'`) — CARDINALITIES below — and each
+ * `NotationStyle` renders it its own way: Chen turns the relationship
+ * itself into a diamond-shaped node with a plain text label ('1'/'N') on
+ * each connecting edge; Crow's Foot renders it as an arrowhead-style glyph
+ * at the entity end (fork for "many", tick for "one", circle for
+ * "optional" — see the `crowsfoot-*` markers in SVGRenderer.js); UML shows
+ * the multiplicity string itself as a text label near that end
+ * (`edge.sourceLabel`/`targetLabel`, a plain graphDiagram feature, not
+ * data-model-specific). None of these are pixel-perfect renditions of the
+ * real notations' full rule set (Chen's own attribute-oval convention,
+ * every crow's-foot optionality combination, UML's aggregation/composition
+ * diamonds) — they're a representative, genuinely-readable version of each,
+ * the same calibration archimateDiagram's own icons use.
+ */
+
+/** One data-modelling abstraction level. See DataModelNotation.levels(). */
+export class DataModelLevel {
+    constructor(name, description) {
+        this.name = name;
+        this.description = description;
+    }
+
+    /** What a menu calls it ('Conceptual'). */
+    get label() {
+        return this.name.charAt(0).toUpperCase() + this.name.slice(1);
+    }
+}
+
+/** The canonical cardinality vocabulary every NotationStyle renders
+ *  differently — UML-style multiplicity strings, since they're the only one
+ *  of the three notations expressive enough to BE the canonical form
+ *  without losing information (Chen/Crow's Foot each collapse some of these
+ *  distinctions on purpose). */
+const CARDINALITIES = new Set(['0..1', '1', '0..*', '*', '1..*']);
+
+function chenCardinalityLabel(cardinality) {
+    return cardinality === '1' || cardinality === '0..1' ? '1' : 'N';
+}
+
+const CROWSFOOT_ARROWHEADS = {
+    '1': 'crowsfoot-one',
+    '0..1': 'crowsfoot-one-optional',
+    '1..*': 'crowsfoot-many-mandatory',
+    '0..*': 'crowsfoot-many',
+    '*': 'crowsfoot-many',
+};
+
+/**
+ * One drawing technique for entities/relationships — Chen, Crow's Foot, or
+ * UML (class-diagram style). `entityShape` picks the graphDiagram node shape
+ * (`'rect'` for a plain box, `'table'` for a header + attribute-rows card);
+ * `relationshipAsNode` (Chen only) turns a relationship into its own
+ * diamond-shaped node with two plain edges instead of one direct edge;
+ * `cardinalityArrowhead`/`cardinalityLabel` (each `(cardinality) => value or
+ * undefined`) pick how a relationship's own cardinality at one end renders
+ * — at most one of the two is ever set for a given notation, the other
+ * always returns undefined.
+ */
+export class NotationStyle {
+    constructor(name, { label = name, entityShape, relationshipAsNode, cardinalityArrowhead, cardinalityLabel }) {
+        this.name = name;
+        /** What a menu calls it ("Crow's Foot"). */
+        this.label = label;
+        this.entityShape = entityShape;
+        this.relationshipAsNode = relationshipAsNode;
+        this.cardinalityArrowhead = cardinalityArrowhead;
+        this.cardinalityLabel = cardinalityLabel;
+    }
+}
+
+const LEVELS = {
+    conceptual: new DataModelLevel('conceptual', 'Entities and their relationships only — no attributes, no keys, no types.'),
+    logical: new DataModelLevel('logical', 'Attributes and keys, still database-agnostic — no column types or engine specifics.'),
+    physical: new DataModelLevel('physical', 'Real column types, keys, and constraints as they exist in an actual database.'),
+};
+
+const NOTATIONS = {
+    chen: new NotationStyle('chen', {
+        label: 'Chen',
+        entityShape: 'rect',
+        relationshipAsNode: true,
+        cardinalityArrowhead: () => undefined,
+        cardinalityLabel: chenCardinalityLabel,
+    }),
+    crowsfoot: new NotationStyle('crowsfoot', {
+        label: "Crow's Foot",
+        entityShape: 'table',
+        relationshipAsNode: false,
+        cardinalityArrowhead: (cardinality) => CROWSFOOT_ARROWHEADS[cardinality],
+        cardinalityLabel: () => undefined,
+    }),
+    uml: new NotationStyle('uml', {
+        label: 'UML',
+        entityShape: 'table',
+        relationshipAsNode: false,
+        cardinalityArrowhead: () => undefined,
+        cardinalityLabel: (cardinality) => cardinality,
+    }),
+};
+
+export const DataModelNotation = {
+    levels() { return Object.values(LEVELS); },
+    levelNames() { return Object.keys(LEVELS); },
+    level(name) { return LEVELS[name]; },
+    notations() { return Object.values(NOTATIONS); },
+    notationNames() { return Object.keys(NOTATIONS); },
+    notation(name) { return NOTATIONS[name] || NOTATIONS.crowsfoot; },
+    isCardinality(value) { return CARDINALITIES.has(value); },
+    cardinalities() { return [...CARDINALITIES]; },
+};

package/src/diagramCatalog.js

@@ -1,30 +1,35 @@
-/**
- * Single source of truth for "what diagram types does RenderEngine support".
- *
- * Mirrors src/chartCatalog.js: the registry is the object-oriented lookup
- * layer over the flat catalog, and `getDiagramCatalogEntry` is the legacy-style
- * helper kept for backward compatibility.
- */
-
-import { DiagramRegistry } from './charting/DiagramRegistry.js';
-import { GraphDiagram } from './charting/diagrams/GraphDiagram.js';
-import { GraphDiagram3D } from './charting/diagrams/GraphDiagram3D.js';
-import { ArchimateDiagram } from './charting/diagrams/ArchimateDiagram.js';
-import { DataModelDiagram } from './charting/diagrams/DataModelDiagram.js';
-import { EbnfDiagram } from './charting/diagrams/EbnfDiagram.js';
-
-export const DIAGRAM_CATALOG = [
-    { key: 'graph', method: 'graphDiagram', DiagramClass: GraphDiagram },
-    { key: 'graph3d', method: 'graphDiagram3D', DiagramClass: GraphDiagram3D },
-    { key: 'archimate', method: 'archimateDiagram', DiagramClass: ArchimateDiagram },
-    { key: 'dataModel', method: 'dataModelDiagram', DiagramClass: DataModelDiagram },
-    { key: 'ebnf', method: 'ebnfDiagram', DiagramClass: EbnfDiagram },
-];
-
-/** Canonical registry instance seeded with the built-in diagram types. */
-export const diagramRegistry = new DiagramRegistry(DIAGRAM_CATALOG);
-
-/** Look up one catalog entry by key, or undefined if the key is unknown. */
-export function getDiagramCatalogEntry(key) {
-    return diagramRegistry.get(key);
-}
+/**
+ * Single source of truth for "what diagram types does RenderEngine support".
+ *
+ * Mirrors src/chartCatalog.js: the registry is the object-oriented lookup
+ * layer over the flat catalog, and `getDiagramCatalogEntry` is the legacy-style
+ * helper kept for backward compatibility.
+ */
+
+import { DiagramRegistry } from './charting/DiagramRegistry.js';
+import { GraphDiagram } from './charting/diagrams/GraphDiagram.js';
+import { GraphDiagram3D } from './charting/diagrams/GraphDiagram3D.js';
+import { ArchimateDiagram } from './charting/diagrams/ArchimateDiagram.js';
+import { DataModelDiagram } from './charting/diagrams/DataModelDiagram.js';
+import { EbnfDiagram } from './charting/diagrams/EbnfDiagram.js';
+
+/**
+ * Each entry: `key`, the RenderEngine `method` that draws it, its `DiagramClass`,
+ * and `args`: the options a registered diagram (RenderEngine#register) keeps its
+ * data in, in the order the method takes them before its options.
+ */
+export const DIAGRAM_CATALOG = [
+    { key: 'graph', method: 'graphDiagram', DiagramClass: GraphDiagram, args: ['nodes', 'edges'] },
+    { key: 'graph3d', method: 'graphDiagram3D', DiagramClass: GraphDiagram3D, args: ['nodes', 'edges'] },
+    { key: 'archimate', method: 'archimateDiagram', DiagramClass: ArchimateDiagram, args: ['elements', 'relationships'] },
+    { key: 'dataModel', method: 'dataModelDiagram', DiagramClass: DataModelDiagram, args: ['entities', 'relationships'] },
+    { key: 'ebnf', method: 'ebnfDiagram', DiagramClass: EbnfDiagram, args: ['rule'] },
+];
+
+/** Canonical registry instance seeded with the built-in diagram types. */
+export const diagramRegistry = new DiagramRegistry(DIAGRAM_CATALOG);
+
+/** Look up one catalog entry by key, or undefined if the key is unknown. */
+export function getDiagramCatalogEntry(key) {
+    return diagramRegistry.get(key);
+}