8.2.3. Build und Vorschau
Build and Refresh verbindet den bearbeiteten Projektstand mit ausführbarem Vorschaucode. Eine normale IntelliJ-Kompilierung oder ein separat gestarteter Maven-Build aktiviert noch keinen neuen Designer-Build.
Der Designer ermittelt die benötigten Module des gewählten Maven-Reaktors, kopiert die Eingaben in einen privaten Build und erfasst dessen Ergebnisse. Erst nach Erfolg wird ein unveränderlicher Snapshot veröffentlicht. Dieser enthält auch die verwendeten Abhängigkeiten und generierten Metadaten. Laufende Worker halten den Snapshot über eine Nutzungssperre verfügbar.
Die veränderlichen target-Verzeichnisse des ursprünglichen Projekts sind damit nicht die Laufzeit der Vorschau. Ein fehlgeschlagener Build kann keine teilweise erzeugten Klassen oder Metadaten aktivieren.
Nicht gespeicherte Java-, POM- und Konfigurationsänderungen müssen vor der Kompilierung über den ausdrücklich bestätigten Speicherablauf übernommen werden. Die Bestätigung gilt für die konkreten Revisionen; eine danach hinzugekommene Änderung wird nicht unbemerkt mitgespeichert. FXML-Entwürfe können dagegen als private Ressourcenüberlagerung an die Vorschau gehen, ohne zuerst gespeichert zu werden.
Nach einem Fehler oder einer Java-Änderung wird nicht automatisch alter Code gestartet. Preview last successful wählt den letzten erfolgreichen Build ausdrücklich. Die Oberfläche kennzeichnet diesen älteren Stand, bis ein neuer Build erfolgreich ist.
Standardsteuerelemente stellt der Kit unmittelbar dar. Für Anwendungs-Components verwendet er eigene Platzhalter. Der Zielprozess lädt die echte übergeordnete View mit Beispieldaten, misst die Components und liefert Bilder sowie Größenangaben zurück. Der Host konstruiert keine Anwendungsklassen.
Beim Verschieben oder Vergrößern bleibt das bisherige Bild sichtbar, während die neue Größe im Hintergrund gerendert wird. Ein Ergebnis wird nur übernommen, wenn Dokumentrevision, Größe und Sitzung noch passen. Dadurch kann eine langsamere ältere Antwort keine neuere Bearbeitung überschreiben.
Bevorzugte und minimale Größen aus der Ziel-Laufzeit ergänzen die ausdrücklich gesetzten FXML-Layoutwerte. Geschachtelte und anonyme Components sowie fx:root-Inhalte werden über dieselbe Projektion bearbeitet. Ein wiederholtes Besuchsformular ist zur Laufzeit mehrfach vorhanden; seine Definition steht trotzdem nur einmal in VisitForm.fxml.
Die Zeichenfläche ist ein Editor. Für das Anklicken von Anwendungsschaltflächen und die Prüfung der Model-Rückschreibung wird die interaktive Vorschau verwendet.
Interactive preview startet einen getrennten Zielprozess mit einem neuen Model-Graphen und Injection-Kontext. Er erhält die aktuelle View und die bekannten geöffneten Component-Entwürfe. Sein Zustand ist unabhängig vom Model der Zeichenfläche.
Restart erzeugt erneut frische Beispieldaten. Stop preview beendet nur die zugehörige Vorschau. Wird ihr Editor geschlossen, wird auch diese Vorschau beendet; andere Editoren und Vorschauen bleiben geöffnet.
Eine spätere FXML-Eingabe zerstört den interaktiven Zustand nicht sofort. Die Vorschau bleibt geöffnet und zeigt an, dass sie einen früheren Entwurf verwendet. Beim Speichern eines betroffenen Dokuments startet sie mit frischen Beispieldaten neu. Auch ein ausdrücklicher Neustart übernimmt die aktuellen Entwürfe und entfernt die entsprechende Kennzeichnung.
Bekannte Binding-Fehler verhindern neue Vorschauen. Der Quelltext kann trotzdem bearbeitet, gespeichert und mit Undo/Redo wiederhergestellt werden. Java- und Konfigurationsänderungen benötigen weiterhin einen erfolgreichen Build oder die ausdrückliche Wahl des älteren Builds.
Open Component öffnet die passende Quelldatei oder aktiviert deren vorhandenen Editor. Die übergeordnete View bleibt geöffnet und ihr Layout unverändert. Standalone verwendet getrennte Fenster, IntelliJ weitere Editor-Tabs. Open Row Component ist die entsprechende ausdrückliche Aktion für eine Tabellenzeile.
Bearbeitbar sind eindeutig zugeordnete Projektressourcen. Eine Ressource innerhalb eines Abhängigkeits-JARs wird dadurch nicht automatisch zur editierbaren Projektdatei. Neue Dateien und Provider-Beschreibungen müssen erst in den erfassten Build aufgenommen werden.
Eine Vorschau führt Java-Code der Anwendung aus. Der getrennte Prozess hält Anwendungsklassen und native JavaFX-Bibliotheken aus dem Host heraus, ist aber keine Betriebssystem-Sandbox. Für Beispiele sollten deshalb gezielt geeignete Dienste verwendet werden.
Das Protokoll begrenzt Entwürfe auf 128 Dateien mit jeweils höchstens 1 MiB und begrenzt außerdem Bilder und Gesamtnutzlasten. Ressourcen müssen eindeutig auf die erfassten Quellverzeichnisse abgebildet werden können. Die Veränderung signierter JARs für Entwurfsüberlagerungen wird abgelehnt.
Schließen, Abbrechen und Verlust des Host-Prozesses lösen eine zeitlich begrenzte Worker-Beendigung aus. Provider räumen eigene Timer, Listener und Dienste in close() auf. Erzwingt der Host das Prozessende, kann diese Anwendungsmethode nicht mehr zuverlässig ausgeführt werden. Kleine, unabhängige Beispielsitzungen erleichtern daher sowohl das Arbeiten als auch die Fehleranalyse.