= 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|http://www.eclipse.org], Basis der EclipseIDE, basiert auf SWT
* [Netbeans Platform|http://www.netbeans.org], Basis der NetbeansIDE, basiert auf [Swing]
* [Java Application Framework|http://appframework.dev.java.net], basiert auf [Swing]
* [JGoodies|http://www.jgoodies.com]
* [Griffon|http://griffon-framework.org/][Griffon|http://griffon.codehaus.org/] - Grails-ähnlicher Baukasten für Desktop-Applikationen mit Swing-Application Framework<< (siehe auch [Groovy-Usergroup|http://ggg.mixxt.de/] München)
* [Apache Pivot|http://pivot.apache.org] Interessantes Framework, um Rich Internet Applications in Java (als Applet) zu bauen, Alternative zu JavaFX

Die beiden ersten Ansätze sind relativ gut dokumentiert und dürften
auch recht verbreitet sein. Allerdings dürfte man sich damit eine
Menge Monster-Bibliotheken einfangen. Die Zeit, die man vielleicht
spart, weil einiges bereits fertig programmiert ist, benötigt man
dann stattdessen dazu, sich durch die Anleitung zu graben.

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/ sollte es in Java7 integriert werden, laut http://openjdk.java.net/projects/jdk7/features/#f650 ist da aber vorerst nichts draus geworden.

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|https://sam.dev.java.net/] aufbauende JavaActions benutze, ist das etwas ärgerlich.

Obwohl es angeblich [Teil von Java7 werden soll|http://tech.puredanger.com/java7/] 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|http://weblogs.java.net/blog/alexfromsun/archive/2009/03/swing_applicati_1.html] 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|https://sam.dev.java.net/]). 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.

=== Property-Injection - zentrale Verwaltung von Resourcen für die Applikation ===

erlaubt Konfiguration der GUI, Skins, Lokalisation, etc. z.B. über einen ~ResourceManager und 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

=== GUI-Generation ===

Einige GUI-Elemente wie das Menü oder eine Statusleiste fallen sicherlich mit in den Fokus eines Application Framework (oder ist das die Aufgabe des Action Frameworks wie auf JavaActions beschrieben?). Es ergeben sich auf jeden Fall Überschneidungen und Schnittstellen zu dem Code, der letztlich die eingentliche Nutz-GUI darstellt. Daher ist auf die Zusammenarbeit mit GUI-Generatoren (z.B. XUL-Generatoren wie [Swixml|http://www.swixml.org] oder [CookSwing|http://cookxml.yuanheng.org/cookswing/index.html] oder der YAML-Generator [SwingJavaBuilder|http://code.google.com/p/javabuilders/]), Formulargeneratoren, etc. zu achten. Die Verknüpfung sollte jedoch nicht zu stark sein, da hier jeder Programmierer seinen eigenen Lieblings-Weg haben wird...

Auf der [Swixml-Homepage|http://www.swixml.org] gibt es übrigens über die guten Beispiele hinaus sehr wenig Doku. Ich empfehle, folgendes zu lesen: [deutscher Artikel|http://sw-dev.at/doku.php/module_des_erfolgs/swixml] mit guter [Beispiel-Sammlung|http://sw-dev.at/doku.php/module_des_erfolgs/swixml_beispiele], [Artikel auf java.net|http://today.java.net/pub/a/today/2006/02/21/building-guis-with-swixml.html], [Artikel auf devarticles.com|http://www.devarticles.com/c/a/XML/UI-Design-with-Java-and-XML-Toolkits/].

Und nicht vergessen: Auf eine generierte GUI folgt zumeist ein anständiges Binding wie [BeansBinding|http://weblogs.java.net/blog/zixle/archive/2006/05/ease_of_swing_d.html] oder [JGoodies Binding|http://www.javalobby.org/java/forums/t17672].

=== Standard-Dialoge ===

Einfache Erstellung von häufig gebrauchten einfachen Dialogen über ~JOptionPane hinaus. (siehe unten, Arbeitstitel "[JDialog]")



= 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? Unser Projekt findet Ihr auf der Seite LugFramework.

--ThomasBayen

: Gute Idee - mir würde wahrscheinlich schon so eine Emulation von bzw. ein Interface zu XDialog, KDialog, CDialog, GDialog, Zenity oder Whiptail unter Java genügen, die mir 80% meiner Anwendungsfälle abdecken. So einen Wrapper wie perl's [UI::Dialog|http://search.cpan.org/~kck/UI-Dialog-1.08/lib/UI/Dialog.pod#ABSTRACT] habe ich jedoch unter Java noch nicht entdeckt. --MarkusMonderkamp

:: Eine solches "JDialog" könnte eine gute erste Anwendung sein, in der man das Zusammenspiel unserer Komponenten üben könnte. Andererseits könnte es dann auch integraler Bestandteil des Framework werden. Das ist ein Ziel, das für einen "Technologie-Test" verschiedener Komponenten nicht zu einfach und nicht zu schwierig ist. -- ThomasBayen



== eine grundlegende Swing-Applikation ==

Auf dem LUG-Treffen am 15.6.09 haben ThomasThiessen und ThomasBayen überlegt, welche Komponenten man für eine Basis-Anwendung bräuchte, die in Richtung Datenbank bzw. WarenWirtschaft (oder auch VereinsVerwaltung) geht. Dabei ist die folgende Auflistung entstanden. Wir haben überlegt, die dort angesprochenen Themen zu den nächsten LUG-Treffen zu bearbeiten, zu besprechen und ggf. Empfehlungen auszusprechen. Für das nächste Treffen schlage ich vor, daß wir uns dem Thema "Projektumgebung" widmen, um eine gemeinsame Basis zu schaffen. Vielleicht wird ja eine Artikelserie daraus...

* [SwingApplikation.Projektumgebung]



=== GUI ===
* Erstellung der GUI in Java und/oder in XML und/oder mit Groovys ~SwingBuilder
* Menüs, Toolbars und Actions
** verschiedene Befehlssammlungen ineinander schachteln
** Rechteverwaltung
* Sessionmanagement (Fenster öffnet in der bekannten Größe an der alten Stelle)
* Tabellen sortier- und filterbar und mit Sessionmanagement


=== Benutzerverwaltung ===
* Ablage der Benutzerdaten wie und wo


=== Datenbankverbindungen ===
* Verwaltung in einer Art Datenbank ohne Datenbank \\[SQLite|http://www.sqlite.org/] bzw. in Java besser [HSQLDB|http://hsqldb.org] oder [Derby|http://db.apache.org/derby/] oder lieber serialisiert als XML-Datei?
* Wechsel zwischen mehreren vorkonfigurierten Einstellungen
* Speichern in lokaler Datei \\ Will man Webstart- und Applet-fähig sein, muss man ein ~LocalStorage in Form eines einzelnen Dateistreams benutzen. Das spricht gegen gängige Datenbanken und für XML. Denkbar wäre auch eine "hsqldb:mem"-Datenbank im Speicher, die man dann mit dem [TransferTool|http://hsqldb.org/doc/guide/apg.html] dumpt bzw. restored.
** Wieviele Datenbankverbindungen braucht Ihr denn?
** Was spricht gegen eine ganz normale Properties-Datei? --Peter

Wir haben uns für die Speicherung serialisiert als XML-Datei entschlossen. Zum einen gibt es dafür bereits fertige Lese- und Schreib-Methoden in der Standardbibliothek. Zum anderen erlaubt das die leichte Erweiterung, indem das serialisierte Objekt erweitert oder abgeleitet wird.



=== Datenbank ===
* [[JDBC]] oder JPA (JavaHibernate)
* Einrichten der Datenbank durch das Programm



=== Applikationsumgebung ===
* API für lokale Dateien (LocalStorage des Java Application Framework)
* standardisiertes Fenster mit Menü, Toolbar, Statusleiste, Sessionmanagement
* einheitliches Look & Feel
* Hilfesystem



=== Formulare ===
* Plausibilitätsprüfungen
* automatische Erstellung von Formularen


=== Benamung von Klassen, Methoden und Variablen ===
* einheitliches System
* deutsche Schreibweise von Fall zu Fall?


=== Dokumentation ===

Wir haben uns entschlossen, für die Dokumentation des Projektes als Basis JavaDoc zu nehmen und für den Rest direkt eine Website zu erstellen, auf der dann weitere Artikel (wie Tutorials, etc) direkt als HTML-Dokumente eingebunden sind. Diese Seite findet man unter http://lugframework.javaproject.de . Sie wird mit Hilfe von ApacheAnt durch ein automatisiertes Ant-Skript erzeugt, das ich FlyingAnt getauft habe.


=== Splash-Screen ===

Seit Java6 gibt es eine ordentliche Unterstützung für Splashscreens. Die Einführung ist unter http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/splashscreen/ zu finden und die API-Dokumentation unter http://java.sun.com/javase/6/docs/api/java/awt/SplashScreen.html.

Diese originale Implementation hat gegenüber allen anderen den grossen Vorteil, daß sie schon _vor_ dem Starten der Java VM den Splashscreen anzeigt. Damit dürfte Sie eine halbe Sekunde schneller als andere sein. Wie in der Einführung kann man diesen dann als erste Amtshandlung übermalen oder auch durch ein Swing-Fenster ersetzen, wenn man selber Einfluss nehmen will, um z.B. den Fortschritt der Programminitialisierung anzuzeigen.


=== Erinnerung ===

* Parameter für GridbagLayout


----
[{Tag Java Swing Projekte LugFramework}]