====== 4. VSIX-Module — Gesamtübersicht ======
//Stand: 2026-03-06//
Übergeordnet: [[de:int:wvdsshell:notes:start|WvdS-Plattform — Gesamtübersicht]]
Verwandt: [[de:int:wvdsshell:notes:02-cafm:start|2. CAFM-Architektur ←]] | [[de:int:wvdsshell:notes:03-pims:start|3. PIMS-Architektur ←]] | [[de:int:wvdsshell:notes:04-vsix:amed-cafm|4.1 CAFM-Extension]] | [[de:int:wvdsshell:notes:04-vsix:amed-pims|4.2 PIMS-Extension]]
===== Einordnung =====
Die Seiten 01-siam, 02-cafm und 03-pims dokumentieren die **Backend-Architektur** — Authentifizierung, Bestandsdaten und Prozessdaten. Diese Seite dokumentiert die **Präsentationsschicht**: Welche VSIX-Module sieht der Benutzer, wie sind sie strukturiert, und in welcher Reihenfolge werden sie ausgeliefert?
WvdS.Shell lädt Erweiterungen als ''.wvdx''-Pakete (identisch mit ''.vsix'' im Format). Jede Erweiterung bringt eigene Views, Forms und TreeView-Provider mit, kommuniziert über HTTPS/JWT mit dem Gateway.Service und rendert ihre Oberfläche in WebView-Panels (CEF). Die ShowCase-Extension (''wvds-show-case'') dient als kanonische Referenz für Verzeichnisstruktur, Build-Pipeline und Code-Konventionen.
===== Modul-Übersicht =====
^ Extension ^ DB-Schicht ^ Views (Topics) ^ Zweck ^ Status ^
| **wvds-amed-cafm** | ENIVERSCAFM | CAFM-TP, CAFM-OBJ, CAFM-EMR | Bestandsführung: Technische Plätze, Equipment, Elektrik | Geplant |
| **wvds-amed-pims** | ENIVERSPIMS | PIMS-INSP, PIMS-EZA, PIMS-WORK, PIMS-PIPE | Prozessführung: Prüfungen, Sicherheit, Aufträge, Rohrleitungen | Geplant |
| **wvds-amed** | — | — | Extension Pack (Bundle) — aggregiert beide Einzelextensions | Geplant |
===== Granularitätsentscheidung =====
^ Ebene ^ Einheit ^ Beispiel ^
| **Deployment** | Domain-Extension (''.wvdx'') | ''wvds-amed-cafm'' = 1 Paket, 1 Installation |
| **Navigation** | Topic (View/Panel innerhalb der Ext) | CAFM-TP, CAFM-OBJ, CAFM-EMR = 3 Views in 1 Extension |
| **Migration** | Work Package (WP) | CAFM-TP WP-01 bis WP-07 füllen die TP-Views schrittweise |
Die Entscheidung gegen eine Extension pro Topic (z.B. ''wvds-amed-cafm-tp'') ist bewusst: Der Overhead von 7+ Extensions wäre hoch, die Abhängigkeiten komplex, und kein Anwender installiert TP ohne OBJ. Die Domain-Ebene entspricht der Drei-Datenbank-Architektur und hält die Deployment-Einheit handhabbar.
===== Dependency Chain =====
WvdS.Shell (FPC/Lazarus)
└── Auth: PFX → JWT (Shell-intern, ENIVERSSIAM)
│
├── wvds-amed-cafm [keine Extension-Dependencies]
│ ├── TreeView: amedCafmExplorer
│ ├── Views: TP, OBJ, EMR
│ └── Gateway: GET/POST /api/v1/cafm/*
│ └── ENIVERSCAFM (org.*, asset.*)
│
└── wvds-amed-pims [keine Extension-Dependencies]
├── TreeView: amedPimsExplorer
├── Views: INSP, EZA, WORK, PIPE
└── Gateway: GET/POST /api/v1/pims/*
├── ENIVERSPIMS (inspection.*, work.*, safety.*, fault.*)
└── Cross-Ref → ENIVERSCAFM (asset.item via Synonym)
Die Extensions sind **voneinander unabhängig** — kein ''extensionDependencies'' untereinander. Der gemeinsame Nenner ist ausschließlich der JWT-Token, den WvdS.Shell bereits bereitstellt. Ein Anwender kann nur CAFM oder nur PIMS installieren, ohne dass die andere Extension fehlt.
===== Extension Anatomy =====
Jede Business-Extension folgt dem ShowCase-Vorbild:
wvds-amed-{domain}/
├── src-pas/
│ ├── extension.pas ← Entry point (Activate / Deactivate)
│ ├── {Domain}.Interop.pas ← JS/asm interop (nur asm-Blöcke)
│ ├── {Domain}.{Topic}.pas ← 1 Unit pro Topic/View
│ │ z.B. Cafm.TechPlace.pas, Cafm.Objects.pas, Cafm.Emr.pas
│ ├── services/
│ │ ├── Services.Lifecycle.pas ← Extension-Lifecycle, Feature-Flag-Auswertung
│ │ └── Services.Gateway.pas ← HTTP/REST-Client → Gateway.Service
│ └── tree/
│ └── Tree.{Domain}.pas ← TreeView-Provider (Sidebar-Navigation)
│
├── forms/
│ └── {Topic}.wfm ← 1 WFM-Form pro Screen (JSON-Format)
│ z.B. TechPlace.wfm, TechPlaceDetail.wfm, Objects.wfm
│
├── media/
│ └── icons/
│ ├── activity-bar.svg ← Activity-Bar-Icon
│ └── {domain}.svg ← Allgemeines Domain-Icon
│
├── dist/ ← pas2js Output (extension.js + .map)
├── package.json ← Extension-Manifest
├── package.nls.json ← Englische Strings
├── package.nls.de.json ← Deutsche Strings
├── build.ps1 ← Build-Skript (pas2js, Packaging)
├── CLAUDE.md ← Projekt-Richtlinien
└── .vscodeignore ← Packaging-Ausschlüsse
==== Form-Dateien (WFM) ====
Forms werden als JSON im WFM-Format definiert — kein Binary wie bei Delphi. ''property_schema'' aus ENIVERSCAFM beschreibt, welche Felder ein Formular zur Laufzeit zeigt. Ein neuer Gerätetyp in ''property_schema'' ergibt automatisch ein neues Formular — ohne Pascal-Code-Änderung.
{
"version": "1.0",
"form": {
"name": "TechPlace",
"className": "TWvdSForm",
"layout": "flexColumn",
"children": [
{ "type": "TwvdsTextEdit", "name": "edtItemNumber", "bind": "item_number" },
{ "type": "TwvdsComboBox", "name": "cboTypeCode", "bind": "type_code" },
{ "type": "TwvdsPropertyGrid", "name": "pgProperties", "bind": "properties" }
]
}
}
===== Kommunikation: Shell → Extension → Gateway =====
WvdS.Shell Extension (pas2js) Gateway.Service
│ │ │
│ 1. JWT bereitstellen │ │
│ (IShellContext.Token) │ │
│─────────────────────────────►│ │
│ │ │
│ │ 2. REST-Call mit Bearer-Token│
│ │ GET /api/v1/cafm/tp?branch=3│
│ │─────────────────────────────►│
│ │ │
│ │ 3. JSON-Response │
│ │◄─────────────────────────────│
│ │ │
│ 4. WebView rendern │ │
│◄─────────────────────────────│ │
Der JWT-Token fließt über ''IShellContext'' — eine Schnittstelle, die WvdS.Shell jeder Extension zur Verfügung stellt. Die Extension ruft damit REST-Endpunkte auf dem Gateway auf. Die Antwort (JSON) wird in WFM-Forms gerendert. Der Gateway authentifiziert den Token gegen ENIVERSSIAM und routet die Anfrage an die entsprechende Datenbank.
===== Naming-Konventionen =====
^ Element ^ Muster ^ Beispiel ^
| Extension-Name | ''wvds-amed-{domain}'' | ''wvds-amed-cafm'' |
| Extension-ID | ''wvds.wvds-amed-{domain}'' | ''wvds.wvds-amed-cafm'' |
| Unit-Name | ''{Domain}.{Topic}.pas'' | ''Cafm.TechPlace.pas'' |
| Service-Unit | ''Services.{Service}.pas'' | ''Services.Gateway.pas'' |
| TreeView-Unit | ''Tree.{Domain}.pas'' | ''Tree.Cafm.pas'' |
| Form-Name | ''{Topic}.wfm'' | ''TechPlace.wfm'' |
| Command | ''amed.{domain}.{action}'' | ''amed.cafm.openTechPlace'' |
| TreeView-ID | ''amed{Domain}Explorer'' | ''amedCafmExplorer'' |
| Activity-Bar Icon | ''activity-bar.svg'' | — |
===== Deployment-Reihenfolge =====
Die Auslieferung ist synchron mit den Work Packages im MS-To-Do (Liste ENIV):
^ Phase ^ Voraussetzung ^ Extension-Aktion ^
| Scaffold | — | Extension-Projekte anlegen (''package.json'', ''build.ps1'', leere Forms) |
| Phase A | CAFM-TP WP-01 bis WP-03 abgeschlossen | ''wvds-amed-cafm'': TP-Views aktivieren |
| Phase B | CAFM-OBJ WP-01 bis WP-02 | ''wvds-amed-cafm'': OBJ-Views aktivieren |
| Phase C | CAFM-EMR WP-01 bis WP-02 | ''wvds-amed-cafm'': EMR-View aktivieren |
| Phase D | PIMS-INSP WP-01 bis WP-04 | ''wvds-amed-pims'': INSP-Views aktivieren |
| Phase E | PIMS-EZA + WORK + PIPE WPs | ''wvds-amed-pims'': EZA-, WORK-, PIPE-Views aktivieren |
| Bundle | Alle Phasen | ''wvds-amed'': Extension Pack zusammenstellen |
===== Build-Pipeline =====
^ Schritt ^ Tool ^ Beschreibung ^
| 1 | ''pas2js'' | Pascal → JavaScript (''pas2js -Tnodejs -Jc -Jirtl.js'') |
| 2 | Quality Gate | 0 Errors, 0 Warnings, 0 Hints — keine Ausnahmen |
| 3 | ''build.ps1'' | Packaging: ''dist/extension.js'' + Forms + Media → ''.wvdx'' |
===== Dokumente dieser Sektion =====
^ Nr ^ Dokument ^ Inhalt ^
| 4 | [[de:int:wvdsshell:notes:04-vsix:start|VSIX-Module — Gesamtübersicht]] | Diese Seite — Modul-Map, Dependencies, Anatomy, Naming |
| 4.1 | [[de:int:wvdsshell:notes:04-vsix:amed-cafm|wvds-amed-cafm Extension]] | CAFM-Views (TP, OBJ, EMR), Forms, Gateway-Calls |
| 4.2 | [[de:int:wvdsshell:notes:04-vsix:amed-pims|wvds-amed-pims Extension]] | PIMS-Views (INSP, EZA, WORK, PIPE), Forms, Gateway-Calls |
| 4.3 | [[de:int:wvdsshell:notes:04-vsix:screen-map|Wo finde ich jetzt...?]] | Legacy → VSIX Zuordnung: AMED, LD, WIS, TecDB |
| 4.4 | [[de:int:wvdsshell:notes:04-vsix:view-patterns|View-Patterns — UX-Architektur]] | Leading Pattern, Flyout-Drawer, Tab-Sprung, Legacy-Referenz |