Skip to main content
Entwickler Themen
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

8.2.7. Architektur

Der Host besitzt das bearbeitete Dokument, die Ziel-Laufzeit führt die Anwendung aus. Diese Grenze ermöglicht einen Editor mit JavaFX 26, während die dargestellte Anwendung die geprüfte JavaFX-21-Laufzeit verwendet. Anwendungsklassen und deren native Bibliotheken gelangen nicht in den Klassenlader des Editors.

Die Verarbeitungskette

flowchart TD
    IDE[IntelliJ-Dokumente und Befehle] --> HOST[Host-Service-Verträge]
    APP[Standalone-Dokumente und Fenster] --> HOST
    HOST <--> UI[Gemeinsame Kit-Oberfläche und Quelltextprojektion]
    UI --> CORE[Workflow und Validierung]
    CORE --> BUILD[Isolierter Maven-Build]
    BUILD --> STORE[Unveränderlicher Snapshot]
    CORE --> WORKER[Authentifizierter Zielprozess]
    STORE --> WORKER
    WORKER --> LIB[NeitzelLib ViewLoader und Injection]
    LIB --> MODEL[Frische Models und ViewModels]
    LIB --> VIEW[FXML-Components und Bindings]
    WORKER --> PIXELS[Bilder und Größenangaben]
    PIXELS --> UI
    WORKER --> PREVIEW[Interaktives Vorschaufenster]

Die FXML-Datei bleibt maßgeblich. Der Kit erhält eine bearbeitbare Projektion. Unterstützte Änderungen werden als begrenzte Quelltextersetzungen an den Host zurückgegeben. Dieser prüft die Revision und übernimmt sie in seine normale Dokumenthistorie.

Ein Worker arbeitet mit einem festgelegten Build und konkreten Entwurfsrevisionen. Bilder oder Diagnosen aus einem älteren Auftrag werden nicht auf einen inzwischen veränderten Stand angewendet. Das schützt vor widersprüchlichen Ergebnissen, wenn ein Build, eine Größenänderung oder eine Texteingabe länger dauert.

Module und Abhängigkeiten

Modul Aufgabe
designer-contracts Konfiguration, Metadaten und Protokollwerte ohne Kit- oder IDE-Abhängigkeit
designer-core Build-Verwaltung, Snapshots, Quelltextänderungen, Workflows und Host-Schnittstellen
designer-kit-ui Gemeinsame Oberfläche, Projektion, Binding-Inspektoren und Diagnosen
designer-standalone Lokale Dateien, Fenster und eigenständiger Launcher
designer-intellij Native IDE-Dokumente, Befehle, Navigation, Problems und Toolkit-Prüfung
designer-preview-api Kleiner Java-21-Vertrag für Provider und Sitzungen
designer-target-tools Java-21-Worker, Laufzeitadapter, Erkennung und Rendering
designer-maven-plugin Erfassung der tatsächlich von Maven bestimmten Anwendungslaufzeit
designer-model-processor Optionale Model-Metadaten und Java-ViewModel-Generierung im Build

Die Anwendung verwendet NeitzelLib FX, dessen Core-/Injection-Abhängigkeiten und ihre eigene JavaFX-Version. Sie hängt nicht vom Host ab. PreviewProvider benötigen lediglich die kleine API, möglichst im Test-Scope. Der Model-Prozessor gehört auf den Annotation-Processor-Pfad. Der Host liefert die Worker-Werkzeuge getrennt.

Die Rollen von Model, ViewModel, View und Component erklärt die NeitzelLib-Architektur. Der Designer ergänzt Bearbeitung und Erkennung, ersetzt aber weder das Binding-System noch den Injection-Kontext.

Kommunikation und Lebensdauer

Die Verbindung verwendet authentifizierte Loopback-Sitzungen. Ein zufälliges Token wird über eine reservierte Eingabepipe übergeben, nicht als sichtbares Kommandozeilenargument oder Logausgabe. Protokollnachrichten sind begrenzt und enthalten Kontext-, Build-, Dokument- und Anfrageidentitäten. Standardausgabe und Fehlerausgabe der Anwendung bleiben getrennte Logs.

Der Host besitzt den Worker ausdrücklich. Abbrechen, Editorende und Verlust der Besitzerverbindung führen zu einer zeitlich begrenzten Beendigung. Entwurfsüberlagerungen verwenden private Kopien und verändern keine veröffentlichten Snapshots. Ein noch verwendeter Snapshot bleibt bis zum Ende seiner Nutzung erhalten.

Diese Trennung verhindert inkompatible Klassen- und Toolkit-Mischungen im Host. Sie schränkt den Datei- oder Netzwerkzugriff der Anwendung nicht ein. Vorschaucode benötigt daher dasselbe Vertrauen wie andere ausgeführte Projektprogramme.

Erweiterungspunkte

Ein weiterer Host sollte die Host-Service-Schnittstellen implementieren und Core sowie Kit wiederverwenden. IDE-spezifische APIs gehören nicht in gemeinsame Verträge. Eine andere Anwendungslaufzeit benötigt einen eigenen Zieladapter mit passenden Kompatibilitätsprüfungen; er wird nicht einfach in den Kit geladen.

Neue Binding-Bearbeitungen sollten dieselben revisionsgebundenen Quelltexttransaktionen, die gemeinsame Zielvalidierung und die Host-Historie verwenden. Unbekannte Schema- und Protokollversionen werden ausdrücklich abgelehnt. Eine Erweiterung darf nicht durch stillschweigendes Interpretieren neuer Daten kompatibel erscheinen.

Quellen und Lizenzen

Die Quellen liegen im NeitzelFXDesigner-Repository. Die englische Entwicklerdokumentation im Repository ergänzt diese Kapitel um Formatdetails und Prüfnachweise.

Die schmale Kit-Anpassung zur Textauswahl besitzt dokumentierte Herkunft und erhält den BSD-3-Clause-Hinweis. Für den eigenen Designer-Code ist derzeit noch keine Lizenz festgelegt. Ein öffentlich erreichbares Repository allein erteilt deshalb keine allgemeine Wiederverwendungserlaubnis. Maßgeblich sind die Third-Party-Notices und die jeweilige Quellprovenienz.