18.2    Deklarative und programmierte Oberflächen 

Grundsätzlich können grafische Oberflächen über eine Programm-API aufgebaut werden oder in einer deklarativen Beschreibung spezifiziert werden:

• Programmierte Oberflächen: Der traditionelle Bau von grafischen Oberflächen in Java weist die Besonderheit auf, dass das Design der Oberfläche in Java-Code gegossen werden muss. Jede Komponente muss mit new erzeugt und mithilfe eines Layouts explizit angeordnet werden. Komplexe Oberflächen bestehen dann aus fast unwartbaren Mengen von Programmcode zum Aufbau der Komponenten, zum Setzen der Eigenschaften und zum Platzieren auf dem Container. Die Änderung des Layouts ist natürlich sehr schwierig, da mitunter auch für kleinste Änderungen viel Quellcode bewegt wird. In der Versionsverwaltung sieht das mitunter schrecklich aus.

• Deklarative Oberflächen stehen im Gegensatz zu den programmierten Oberflächen. Bei ihnen sind die Beschreibung des Layouts und die Anordnung der Komponenten nicht in Java ausprogrammiert, sondern in einer externen Ressourcendatei beschrieben. Das Format kann etwa XML sein und spiegelt wider, wie das Objektgeflecht aussieht. Eine Ablaufumgebung liest die Ressourcendatei und übersetzt die Deklarationen in ein Geflecht von GUI-Komponenten. Im Hauptspeicher steht dann am Ende das Gleiche wie bei der programmierten GUI: ein Objektgraph.

 

18.2.1    GUI-Beschreibungen in JavaFX 

JavaFX unterstützt beide Möglichkeiten zum Aufbau von grafischen Oberflächen. Zum einen ist da die klassische API, die Knoten in einen Baum hängt; viel interessanter ist aber der deklarative Ansatz, der sehr schön Präsentation und Logik trennt. JavaFX selbst bietet eine Beschreibung auf XML-Basis, genannt FXML. XML ist selbst hierarchisch, kann also die grundlegende hierarchische Gliederung einer GUI in Containern und Komponenten sehr gut abbilden.

Neben FXML gibt es weitere proprietäre Beschreibungen und Mischformen. Eine davon ist FXGraph vom Projekt e(fx)clipse (http://www.eclipse.org/efxclipse), einer JavaFX-Unterstützung in Eclipse. Die Beschreibung ist eine DSL[ 256 ](Eine Domain Specific Language (DSL) ist eine »Spezialsprache«, die ein exklusives Format für einen klar abgegrenzten Anwendungsfall definiert. ) und definiert den Objektgraphen, der im Hintergrund in FXML umgesetzt wird. FXGraph ist kompakter als FXML und erinnert entfernt an JSON. Auch kann die JavaFX-API in alternativen Sprachen angesprochen werden; JavaScript und weitere Skriptsprachen wie Groovy (mit der Hilfe von GroovyFX[ 257 ](http://groovyfx.org)) oder Scala (zusammen mit ScalaFX[ 258 ](http://www.scalafx.org)) zeigen interessante Wege auf. Allerdings mischt sich dann doch wieder schnell die Deklaration der GUI mit Logik, was die Trennung zwischen Präsentation und Logik aufweicht. Es ist guter Stil, die Beschreibung der Benutzerschnittstelle und der Logik zu trennen, um auch Tests leichter zu realisieren.

 

18.2.2    Deklarative GUI-Beschreibungen für Swing? 

Für AWT und Swing hat sich in den letzten Jahren kein Standard für deklarative Oberflächen gebildet, und Oberflächen werden heute noch so programmiert wie vor 15 Jahren. Dass Swing-Oberflächen immer programmiert werden müssen, hält auf, auch wenn ein GUI-Builder heutzutage die Schmerzen minimiert. Über die WYSIWYG-Oberfläche (What You See Is What You Get) wird in der Regel das Layout mit allen Komponenten zusammengeklickt, und im Hintergrund erzeugt der GUI-Builder den Programmcode. Für die Laufzeitumgebung hat sich also nichts verändert, aber für uns schon.