Eclipse Forms im Härtetest

Probleme aus der Praxis

Es folgt eine kleine Auswahl von praktischen Problemen bei der Erstellung von Masken, um diese Beurteilung zu illustrieren.

  • Disabled State: Werden beispielsweise Text Widgets mit dem Form Toolkit erstellt und der disabled state gesetzt, so ist dies visuell nicht zu erkennen; die Widgets werden exakt so dargestellt wie nicht disablete Widgets.
  • Read-Only State: In vielen Masken werden Widgets benötigt, welche nur zur Anzeige dienen. Im Unterschied zum disabled-Zustand soll der Benutzer aber in der Lage sein, Text aus diesen Feldern zu kopieren. Diesen Zustand gibt es nur für CCombo und Text Widgets (editable), er wird ebenfalls nicht optisch kenntlich gemacht.
  • Mussfelder: Mussfeld-Zustände gibt es auf SWT Widgets nicht; JFace bietet Decorations an. Diese rendern sich allerdings nicht immer korrekt (z.B. in einer ScrolledForm werden sie nicht automatisch gegen das sichtbare Rechteck geclippt und erscheinen außerhalb der Form) und sind auch bei disableten Feldern weiterhin sichtbar, was für Mussfeld-Dekorationen irritierend wirkt.
  • Mindestgröße von Textfeldern: Textfelder passen ihre gewünschte Größe dem enthaltenen Text an, nicht der Anzahl zulässiger Zeichen (textLimit). Wird beispielsweise im GridData kein width hint mitgegeben, so schrumpfen leere Textfelder beim nächsten Layout zu einem mickrigen Klötzchen zusammen, in das nur extrem geduldige User Text eintragen können und wollen. Dummerweise gibt es diesen width hint im TableWrapData erst gar nicht. In einem TableWrapLayout, immerhin dem designierten Standard-Layout für Forms, gibt es also keine Möglichkeit, Textfeldern eine Mindestlänge zu spendieren! Auch hier ist Basteln angesagt.
  • Anpassung von SWT Widgets: Will man die obigen Mängel direkt durch Ableitung eigener Widgets korrigieren, so bekommt man meist eins auf die Finger; der Javadoc-Kommentar zu Widget.checkSubclass() spricht Bände.
  • Unsichtbarmachen von Widgets: Wird in einer Form ein Widget unsichtbar gemacht, so würde manch naiver Zeitgenosse erwarten, dass der dadurch frei gewordene Platz beim Relayout durch andere Widgets genutzt würde. Weit gefehlt. Immerhin gibt’s im GridData ein exclude Flag; setzt man dies vor dem Relayout, so wird der Platz wirklich genutzt.
  • Zustandsänderungen zur Laufzeit: Viele SWT Styles lassen sich nur im Konstruktor ändern; beispielsweise glänzt eine Combo dadurch, dass ihr editable style nicht zur Laufzeit änderbar ist; unter anderem ein Grund, dass eine Custom Combo (CCombo) in SWT aufgenommen wurde.
  • Parent needed: SWT Widgets benötigen einen parent im Konstruktor; sie können somit zur Laufzeit nicht „umgehängt“ werden; das Widget muss destruiert und neu erzeugt werden. Speziell bei dem beliebten SectionPart führt dies dazu, dass solche Parts nicht einfach im Konstruktor beispielsweise eines ViewParts als Parameter mitgegeben werden können, da dieser einen vom Konstruktor losgelösten Lifecycle seiner Widgets verwaltet; Abhilfe schafft nur der komplexitätsfördernde Umweg über eine Factory.
  • Verwirrung: Eine bezeichnende Anmerkung zum vorhergehenden Punkt: ViewParts haben mit SectionParts nur einen Teil des Namens gemeinsam, sind aber völlig unterschiedliche Konzepte, eines entstammt der Welt von JFace, das andere UI Forms. Ihr Programmiermodell unterscheidet sich erheblich.
  • Testen: In SWT gibt es keinen Robot, d.h. keine Klasse, die eine Testautomatisierung, z.B. über JUnit, ermöglicht. Abhilfe gibt es open source als Abbot SWT (Entwicklung scheint etwas eingeschlafen zu sein) oder mittels des hoffnungsvollen Newcomers swtbot. Dieser Support sollte fester Bestandteil eines Widget Toolkits sein.

Im Databinding herrscht nicht die historische Verwirrung wie bei SWT, JFace und UI Forms. Hier entsteht eher der Eindruck, dass das Team nie ein großes Projekt mit vielen Masken umsetzen musste; entsprechend fehlt es an Use-Case-getriebener Dokumentation; die im Wiki zu findenden Informationen sind eher für die Erweiterung des Frameworks als für die direkte Verwendung gedacht.

  • Radio Buttons: Es gibt kein Konstrukt, um eine Gruppe von Radio Buttons an einen Wert zu binden; in den Beispielen findet sich ein RadioGroupManager, welcher fehlerhaft implementiert ist. Dieser sollte besser dokumentiert werden und zum Standardumfang gehören.
  • Combo für Aufzählungsfelder: In jedem Informationssystem gibt es Aufzählungswerte, deren Ausprägungen oft dynamisch erweiterbar in einer Datenbank gespeichert sind, im GUI in Form von Combo-Boxen oder Radio Groups dargestellt werden. Dies sollte ein Standard-Mechanismus und ein aussagekräftiges Beispiel unterstützen.
  • Validierung: Die Validierung und Konvertierung von Werten mittels Update Strategy, Validator und Converter ist sehr flexibel gelöst; birgt allerdings eine Komplexität, mit der ein durchschnittlicher GUI-Programmierer nicht unbedingt konfrontiert werden sollte.
  • Feldübergreifende Validierung: Hier bietet das Data Binding Framework nichts; die Verwendung der Validatoren für diesen Zweck, wie in Beispielen ersichtlich, erscheint dem Autor viel zu umständlich und geht in die falsche Richtung. Hier ist eine Lösung auf Form-Ebene wünschenswert, Best Practices sind Fehlanzeige.
  • ComboViewer: Wird ein ComboViewer an ein Feld gebunden und dieses auf null gesetzt, so wird der Inhalt des Textfeldes in der ComboBox nicht gelöscht.
    Multiselektion in (Checkbox)TableViewer: Ein Binden der Selektion an eine Liste wäre wünschenswert, ist aber nicht vorhanden. Hier steht Abhilfe mit Eclipse 3.4 bereit.
  • Debugging: Da das Databinding über sehr mächtige Abstraktionen arbeitet, ist ein Debugging schwierig; Breakpoints, z.B. im ValueBinding, werden Dutzende Male angesprungen, die gebundene Komponente ist wiederum in ein Observable gewrapped. Hilfreich wäre hier ein Kennzeichnen von Bindungen im Debug-Modus, beispielsweise mittels Farben, Tooltips oder Decorations, um in einer Maske sofort zu erkennen, welche Felder wie gebunden sind.
Fazit

Eclipse RCP liegt bezüglich der Erstellung von formularorientierten User Interfaces weit hinter dem Standard konkurrierender Technologien zurück. Prinzipiell sind die benötigten Bausteine vorhanden. Es fehlt jedoch an stärkerer Orientierung der Dokumentation an den Use Cases, Best Practices für die Auswahl der einzusetzenden Bausteine und gut dokumentierten Beispielen. Mit verhältnismäßig wenig Aufwand und vielen Best Practices lässt sich ein Bündel schnüren, welches den Ansprüchen der Entwickler gerecht wird. Der Autor ist bekennender Eclipse Fan und hat das Sourceforge Projekt RCPForms initiiert, um diese Best Practices, Ergänzungen und Vereinfachungen an einer Stelle zu konzentrieren und Eclipse auch hier zur führenden Plattform zu machen. Mitarbeit ist sehr willkommen. Zu der hier geäußerten starken Kritik an der Eignung von Eclipse zur Erstellung von maskenorientierten Anwendungen sind Flames, Beileidsbekundungen, Diskussionen und konstruktive Kritik willkommen.

Marco van Meegen (www.mvmsoft.de) ist seit 14 Jahren als selbstständiger IT-Berater mit Schwerpunkt J2EE und EAI tätig. Seit Ende 2001 ist er in allen APIs von Eclipse unterwegs, Schwerpunkt EMF, GEF und GMF. Nebenbei hat er zahlreiche Eclipse Plug-ins entwickelt, u.a. Slime UML und RCPForms.
Kommentare

Schreibe einen Kommentar

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