Architektur
Das Studio basiert auf der Charon-Architektur — einem Manager/Mediator-Pattern, das Business-Logik sauber von der UI trennt. Dieses Kapitel beschreibt die Architektur und wie Extensions sich darin einbetten.
Charon-Architektur: Manager & Mediatoren
Die Kern-Architektur folgt einer klaren Schichtenstruktur:
- Manager (
charon/common/) — Plattformunabhängige Services, die State und Business-Logik besitzen - Mediatoren (
charon/browser/) — Brücke zwischen Managern und React-UI-Komponenten - Extensions — Registrieren sich über die
Studio-API (ein Subset von Charon) bei den Mediatoren
Extensions interagieren ausschließlich über die Studio-Klasse (SDK) mit der Anwendung. Die internen Manager und Mediatoren sind nicht direkt zugänglich.
Extension-Lifecycle
Jede Extension durchläuft einen definierten Lebenszyklus:
Drei Lade-Wege
Extensions können auf drei Arten geladen werden:
| Typ | Beschreibung | Verwendung |
|---|---|---|
| Packaged | In der App enthaltene Extensions | Eingebaute Extensions (z.B. bpmn-editor, settings) |
| Dynamic (URI) | Von einer Datei-URI geladen | Externe Extensions im Dateisystem |
| Dynamic (Object) | Programmatisch als JS-Objekt | Zur Laufzeit registrierte Extensions |
Externe Extensions werden mit dem CLI-Flag --extension-development-dir geladen:
/Applications/ProcessCube\ Studio.app/Contents/MacOS/ProcessCube\ Studio \
--extension-development-dir "/pfad/zur/extension"Studio-API: Klassendiagramm
Die Studio-Klasse ist der zentrale Einstiegspunkt für Extension-Entwickler. Sie bietet Zugriff auf alle Funktionsbereiche:
Funktionsbereiche
| Bereich | API | Zweck |
|---|---|---|
| Kommandos | studio.commands | Aktionen registrieren und ausführen |
| Editoren | studio.editors | Dokumenttypen, Öffnen, Speichern |
| Menüs | studio.menus, studio.menuBar | Kontext- und Anwendungsmenüs |
| Panes | studio.panes | Seitenpanels (links, unten, rechts) |
| Activity Bar | studio.activityBar | Icons in der linken Seitenleiste |
| Status Bar | studio.statusBar | Statusleiste am unteren Rand |
| Einstellungen | studio.settings | Konfigurationswerte lesen/schreiben |
| Dialoge | studio.dialog, studio.notifications | Benutzerinteraktion |
| Dateien | studio.files | Datei-I/O-Operationen |
| Engines | studio.engines | ProcessCube-Engine-Verbindungen |
| Events | studio.events | Event-basierte Kommunikation |
| Icons | studio.icons | Icon-Registrierung |
| Umgebung | studio.env | App-Version, OS, Client-Typ |
Sequenzdiagramm: Editor-Dokument
Das Zusammenspiel beim Registrieren und Öffnen eines eigenen Editor-Dokuments:
Model-Renderer-Trennung
Jeder Editor-Dokumenttyp besteht aus zwei Teilen:
- Model (
EditorDocumentModel) — Besitzt die Daten und Business-Logik. Reagiert auf Lifecycle-Events (Save, Close, Focus, Blur). Bietet Undo/Redo. - Renderer (React-Komponente) — Stellt die UI dar. Erhält das Model über Props. Aktualisiert sich bei Datenänderungen.
UI-Bereiche der Anwendung
Die Benutzeroberfläche des Studios ist in klar definierte Bereiche unterteilt. Extensions können jeden dieser Bereiche erweitern:
Zuordnung: UI-Bereich → API
| UI-Bereich | API | Registrierung |
|---|---|---|
| Menu Bar | studio.menuBar | registerMenuBarModifier() |
| Activity Bar | studio.activityBar | registerActivityBarItem(area, id, factory) |
| Editor-Fläche | studio.editors | registerDocumentType(id, config) |
| Panes (links) | studio.panes | registerPaneGroup('left', id, panes) |
| Panes (rechts) | studio.panes | registerPaneGroup('right', id, panes) |
| Panes (unten) | studio.panes | registerPaneGroup('bottom', id, panes) |
| Status Bar | studio.statusBar | registerStatusBarItem(area, id, factory) |
| Kontextmenüs | studio.menus | registerMenu(id, factory) |
| Command Palette | studio.commands | registerInCommandSearch(id, label, callback) |
Nächste Schritte
- Extension-Entwicklung — Praktische Tutorials zum Erstellen eigener Extensions
- API-Referenz — Vollständige Dokumentation aller SDK-Methoden