Swing Application Framework #
Es gibt ein paar Themen und Probleme, die bei der Erstellung von GUI-Applikationen immer wieder auftreten. Um hier das Rad nicht immer wieder neu erfinden zu müssen, bietet es sich an, solche Probleme in Standard-Bibliotheken auszulagern. Die Erstellung einer Applikation wird dadurch beschleunigt und vereinheitlicht.
Diese Seite soll die vorhandenen Lösungen hierfür aufzählen, soweit möglich vergleichen und festhalten, was ein solches Framework überhaupt können soll.
vorhandene Frameworks #
Zur Erstellung einer Desktop-Applikation in Java kenne ich folgende Ansätze:
- Eclipse Platform
, Basis der EclipseIDE, basiert auf SWT
- Netbeans Platform, Basis der NetbeansIDE, basiert auf Swing
- Java Application Framework, basiert auf Swing
- JGoodies
Das JAF ist eine Implementation von JSR-296 und soll so eine Art leichtgewichtige Version der Netbeans-Plattform sein. Laut http://tech.puredanger.com/java7/ soll es in Java7 integriert werden.
JGoodies legt den Haupt-Focus auf das Design der Oberfläche.
Swing oder SWT #
Es ist zu erwähnen, daß die Eclipse-Plattform auf SWT aufbaut, Netbeans und SAF auf Swing.
Der Swing-SWT-Krieg ist ja nun nach einigen Jahren immer noch nicht entschieden. Ich war sehr gespannt, als es hieß, das IBM Sun kaufen wolle, aber da ist ja nun nichts draus geworden. Ich war bisher im Swing-Lager, bin da eigentlich recht zufrieden mit und bringe vor allem einige Erfahrung und meinen alten Code mit, weshalb ich hier zuerstmal Swing-Lösungen bevorzugen möchte. Wer SWT-Erfahrung hat, kann hier aber gerne ergänzen!
Erfahrung mit SAF #
Ich habe einige Projekte mit dem SAF erstellt. Was in der einführenden Dokumentation vorgestellt wird, funktioniert alles gut. Das SAF scheint in erster Linie mit dem GUI-Editor "Matisse", der Teil der Netbeans-Entwicklungsumgebung ist, entwickelt worden zu sein. Dabei ist es wohl grob der Netbeans-Platform ähnlich, so daß der von Matisse erzeugte Code später in beiden Frameworks laufen kann.
Allerdings sind mir auch ein paar Dinge aufgefallen, die mich stören. Eine lästige Eigenschaft ist, daß alle Elemente der GUI über Properties-Dateien konfiguriert werden müssen. Man muss z.B. für die kleinste "Hello-World" Applikation nicht nur eine Applikations-Klasse, sondern immer noch eine Properties-Datei erzeugen, die z.B. den Fenstertitel enthält. Ich finde Properties zur Konfiguration ja sehr praktisch (und aus Sicht von Matisse sind sie sicherlich eine wunderbare Sache) - aber es sollte für alle Einstellungen immer einen Standard-Wert geben, der sich aus dem Klassen-Code ergibt.
Ein weiterer Nachteil ist die Verwendung von Actions, die zwar innerhalb des Frameworks gut funktionieren und denen einige nette Eigenschaften mitgegeben wurden, die allerdings nun nicht mehr ganz kompatibel zu
normalen Actions und nicht mehr so erweiterbar wie diese sind. Da ich eigene, auf SAM aufbauende JavaActions benutze, ist das etwas ärgerlich.
Obwohl es angeblich Teil von Java7 werden soll hat sich am veröffentlichen Code schon lange nichts mehr getan. Auf der Netbeans-Seite (für Matisse) gibt es eine etwas aktuellere Version, deren API sich wundersamerweise wesentlich verändert hat, allerdings keine echte Dokumentation dazu. Neuerdings soll es aber wieder leben Ich zweifle, daß das mit Java7 was gibt, bevor die eigentliche API nicht festgezurrt, dokumentiert und von der Community getestet ist, aber vielleicht reicht Sun ja auch ein interner Review.
Was macht ein Framework alles? #
Die eigentlich interessante Frage ist, was mein Lieblings-Framework alles können soll und was es eben nicht können soll. Deshalb möchte ich hier eine Aufstellung angeben, was alles denkbar ist. Letztlich ist es jedoch
wünschenswert, wenn man jede einzelne dieser Eigenschaften getrennt sieht und durch eine eigene Bibliothek implementiert. Das Beispiel der Actions im SAF sei hier genannt: Zum Thema Actions gibt es ganz tolle
Ideen (z.B. das "Swing Action Framework" SAM). Diese funktionieren aber nicht mit dem SAF zusammen.
Diese Eigenschaften werden in der SAF-Dokumentation genannt:
Verwaltung eines Applikations-Lebenszyklus #
eine logische Aufteilung mit startup, shutdown, Verwaltung mehrerer Fenster, etc.
ResourceManager - zentrale Verwaltung von Resourcen für die Applikation #
erlaubt Konfiguration der GUI, Skins, Lokalisation, etc. z.B. über Properties-Dateien
ActionManager #
die Actions der normalen Swing-API sind noch lange nicht zuende gedacht
SessionStorage - Persistenter Session-Status #
Speichern von Fenstergröße und Position u.a.
LocalStorage - lokaler Speicherbereich für Programmdaten #
automatisierte Erstellung von "~/.applikationsname" bzw. anderer Mechanismen z.B. für Applets
TaskService #
Verwaltung von Hintergrundtasks
Folgende Eigenschaften fallen mir selber darüber hinaus noch ein:
MenuManager #
Erstellung und Verwaltung eines Menüs (ggf. unter Zuhilfenahme der vorhandenen Actions)
DocumentManager #
Verwaltung verschiedener Dokumente mit Standard-GUI-Elementen, um diese zu wechseln, zu Laden, zu Speichern, etc.
UserManager #
Benutzer-Verwaltung braucht man eigentlich auch recht häufig
ExceptionHandler #
einheitlicher Umgang mit Exceptions, z.B. Ausgabe im Dialogfenster
eigenes Framework / eigene Zusammenstellung #
Nach meinen Erfahrungen wäre es sinnvoll, ein Framework zu haben, das wirklich "leightweight" ist und sonst nichts. Ich benutze dann lieber mehrere, (evtl. aufeinander abgestimmte) Komponenten, die ich mir aussuchen oder es auch lassen kann, als mir von meinem Framework alles vorschreiben zu lassen.
Im Grunde geht es also weniger darum, alles neu zu erfinden, als darum, bereits vorhandene Lösungen anzupassen, sinnvoll zu kombinieren und einheitlich zu dokumentieren.
Hat jemand Lust, sowas mitzuerarbeiten?