Formularorientierte GUIs mit RCP erstellen - eine kritische Bestandsaufnahme

Eclipse Forms im Härtetest

Marco van Meegen

Mit der Einführung von RCP hat sich Eclipse nicht nur als IDE, sondern auch als Plattform für Unternehmensanwendungen platziert. Wie schlägt sich RCP bei der Erstellung von grafischen Oberflächen in Informationssystemen, speziell bei formularorientierten Masken mittels SWT, JFace, UI Forms und Eclipse Databinding? Ein Erfahrungsbericht aus dem Einsatz in Großprojekten.

Anforderungen der Benutzer an die Oberflächen von Programmen sind bekannt. Das GUI soll ein ansprechendes Look & Feel haben, den Benutzer durch frühzeitige und klare Fehlermeldungen führen, konsistent und intuitiv erfassbar sein und auch Power-User durch Individualisierbarkeit, schnelle Tastaturbedienung und komfortable Eingabemöglichkeiten überzeugen. Weniger systematisch diskutiert werden die Anforderungen von Entwicklern an ein GUI Toolkit; diese ergeben sich zum einen aus den Requirements der Anwendung, zum anderen daraus, wie leicht sich das API erlernen lässt und wie viel Code für Standardaufgaben wie z.B. Validierung, Abgleich von Widgets mit Modelldaten erforderlich ist. Zu diesen Standardaufgaben zählen:

  • Erstellen von Masken mit Prüfungen
  • Maskenfluss: Existieren Konzepte zum Umsetzen von Masken-Wechseln, z.B. Wizards?
  • Widgets: Textfelder, Buttons, Combo-Boxen, Listen, Tabellen, Trees, Datumswidgets
  • Widget-Zustände: Disabled, Read-Only, Dekorationen für Mussfelder
  • Validierung: Feldvalidierung, z.B. korrekte Eingabe eines Datums in ein Textfeld, feldübergreifende Validierung, z.B. von-Datum kleiner bis-Datum, Mussfelder
  • Gruppen: En/Disablen von Gruppen von Feldern, Ein- und Ausblenden, Wiederverwendung von Gruppen in anderen Masken
  • Binden von Widgets an Datenfelder, Nachführen von Zustandsänderungen eines Widgets im Datenfeld und umgekehrt
  • Layout: flexible Nutzung des verfügbaren Platzes, Anpassung an Größenänderung des Fensters, Schriftgröße und -art, leichte Erlernbarkeit, einfaches Debugging von Layoutproblemen, grafischer GUI Builder
  • Tests

Weiter zählen dazu: Mechanismen, um Felder per boolescher Property als Pflichtfelder zu kennzeichnen, Validierung von Feldwerten schon bei der Eingabe mittels deklarativer Angabe einer Validierungsregel, Widgets zur Erfassung von Standard-Datentypen, z.B. Datumserfassung, E-Mail. Mit einem einzigen Befehl den Datenaustausch eines Textfelds mit einem Wert des Datenmodells definieren, automatische Konvertierung der Werte, wenn man beispielsweise ein Textfeld an einen Integer bindet. Leistungsfähige Layouts die sich automatisch an die Schriftgröße anpassen und den verfügbaren Platz optimal nutzen. Idealerweise sollte ein GUI Framework diese Standardaufgaben leicht machen; der Autor schreckt nicht davor zurück, hier Visual Basic zu erwähnen, mit dessen Hilfe selbst unbedarfte Anwender im Handumdrehen schicke GUIs zaubern können.

Leere Schatztruhe

Schaut man sich das GUI der Eclipse IDE an, so findet man wenig formularorientierte Erfassungsmöglichkeiten. Dominierend sind Texteditoren für Quelltext jeglicher Art, zahlreiche Trees und Tabellen mit nicht änderbaren Werten, einige Wizards und Preferences. Masken im klassischen Sinne, mit Eingabefeldern, Combo-Boxen, Buttons und Feldern mit Mussfeld-Markierung, findet man nur in Ansätzen in den Editoren des Plugin Development Environments. Und hier zeigt sich bereits das Problem. Eclipse wurde nie für die Unterstützung von Eingabemasken entwickelt, ursprünglich nicht einmal für die Entwicklung von etwas anderem als IDEs.

Mit RCP hat sich das geändert, aber bezeichnend ist etwa, dass es in JFace, der Komponente von Eclipse, die für die Erstellung von User Interfaces entwickelt wurde, nicht einmal eine Form-Klasse gibt. Diese steckt in org.eclipse.ui.forms, einem Plug-in, von dem ein unbedarfter Entwickler erwarten würde, dass sich eine Schatztruhe von Bausteinen für die Lösung der oben diskutierten Probleme auftut. Allerdings erwartet ihn beim Öffnen der Truhe eine Enttäuschung, und das lässt sich wiederum aus der Historie erklären: Ursprünglich waren die enthaltenen Klassen entstanden, um die Manifest-Editoren der PDE zu erstellen. Auf Drängen der Community wurden diese halbherzig veröffentlicht und dümpelten mit unausgereiftem, schlecht dokumentiertem API und fehlerbehafteter Implementierung (Beispiel: TableWrapLayout hatte bis inklusive Eclipse 3.2.2 gravierende Fehler in der Layout-Berechnung) vor sich hin. Mit der Geburt der Rich Client Plattform stieg die Bedeutung der org.eclipse.ui.forms sprunghaft, leider resultierte dies nicht in entsprechend erhöhter Entwicklungstätigkeit seitens der Eclipse Community, sodass wichtige Funktionalität bis heute fehlt.

Das Eclipse Databinding fristete auch lange Zeit ein Schattendasein, mit Eclipse 3.3 wurde es erstmals als fester Bestandteil der Plattform ausgeliefert. Die zentrale Klasse ValueBinding wird in der gesamten Plattform nicht ein einziges Mal verwendet. Entsprechend unausgereift auch hier der Umfang, speziell aber die Dokumentation. Allerdings wurde auf eine saubere Architektur mit wenigen wohldefinierten Interfaces Wert gelegt, sodass zu hoffen ist, dass Databinding vielleicht schon in Eclipse 3.4 das liefert, was man davon erwartet.

SWT selbst als Basis für die Widgets krankt an der Multi-Plattform-Problematik, welche Sun vor mehr als zehn Jahren bewog, anstatt AWT weiter aufzubohren, die Widgets selbst zu zeichnen: Swing war geboren. Von SWT Widgets dürfen meist keine eigenen Ableitungen erstellt werden, sodass zur Erweiterung entweder Custom Widgets (die meist nicht mehr den nativen Look unterstützen) oder Wrapper um die SWT Widgets notwendig sind. Mit der Einführung erweiterter Grafik-Operationen und Owner-Draw-Unterstützung für Tables und Trees sieht es hier seit Eclipse 3.2 deutlich besser aus.

Den Glanz, die Flexibilität und Eleganz, die Eclipse binnen weniger Jahre von einer Plattform für IDEs zum Eclipse Universe, dem Shooting Star im Java-Himmel aufsteigen ließ, findet man am ehesten in JFace. Sorgfältig definierte, sehr gut dokumentierte Interfaces, eine moderne Viewer/Content/Label-Provider-Architektur, umfassende und extrem flexible Unterstützung von Texteditoren – hier lebt das beeindruckende UI der Eclipse IDE. Fazit: SWT, JFace, UI Forms und Databinding bilden die Eckpfeiler der Formular-Unterstützung von Eclipse; in Eclipse 3.3 präsentieren sie sich als unausgereiftes Stückwerk von kaum aufeinander abgestimmten Komponenten.

Geschrieben von
Marco van Meegen
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.