Auslaufmodell

Was Sie über UI-Layout-Programmierung nicht mehr wissen müssen

Jonas Helming, Maximilian Kögel
©Shutterstock/ igor.stevanovic

Ein neues Feature der EMF Client Platform ermöglicht das Erzeugen von formularbasierten Oberflächen auf Grundlage eines Layoutmodells. Ein solches Modell beschreibt den Aufbau von formularbasierten Oberflächen innerhalb von Editoren oder Views. Wie bei Eclipse 4 ist das Modell unabhängig von der verwendeten Oberflächentechnologie und wird zur Laufzeit von einem Renderer dargestellt. Der Ansatz ist effektiver als das manuelle Erstellen von Layouts und sorgt gleichzeitig für ein homogenes „Look and Feel“ der entwickelten Oberflächen. Die entstehenden Oberflächen können in beliebige Anwendungen integriert werden, egal ob Eclipse RCP 3.x, Eclipse 4 – oder gar reines Java.

Eclipse 4 hat es vorgemacht: Statt den Aufbau von Views, Perspektiven und Fenstern mühsam in Sourcecode oder weit verstreuten Extension Points definieren zu müssen, gibt es ein zentrales, homogenes Modell. Mit der Unterstützung der e4-Tools kann damit sehr übersichtlich und effektiv das generelle Design einer Anwendung festgelegt werden. Zusätzlich macht dieser Ansatz das Design unabhängig von einer konkreten Oberflächentechnologie. Für Eclipse 4 existieren beispielsweise Renderer für SWT und JavaFX. Der Ansatz beschränkt sich allerdings nur auf den groben Aufbau einer Anwendung. Der Inhalt von Views und Editoren muss weiterhin von Hand und abhängig von einer konkreten Technologie implementiert werden. Neben dem hohen Aufwand sorgt dieses Vorgehen oft für ein inhomogenes Layout einzelner Views. Anders die im Folgenden vorgestellte Alternative: Hier werden formularbasierte Oberflächen auf Grundlage eines Layoutmodells erstellt.

Die EMF Client Platform
Das offizielle Eclipse-Open-Source-Projekt „EMF Client Platform“ ist ein Framework, um die Anwendungsentwicklung basierend auf EMF-Objekten zu unterstützen. Neben dem beschriebenen formularbasierten Editor stellt sie noch weitere optionale Komponenten, beispielsweise Baumansichten sowie verschiedene serverbasierte Backends zur Verfügung. Alle Komponenten haben gemeinsam, dass sie ohne initialen Aufwand zu verwenden sind, aber im Anschluss angepasst werden können.
Die Implementierung des im Artikel beschriebenen Ansatzes ist unabhängig von UI-Technologien und allen anderen Komponenten der EMF Client Platform. Daher kann er beliebig an das eigene Projekt angepasst werden. Insbesondere für die ersten Schritte bietet die EMF Client Platform bereits einen vollständigen Anwendungsrahmen inklusive Persistenz. Damit lassen sich ohne eigene Anwendung die beschriebenen Konzepte leicht ausprobieren. Mehr dazu unter [1].

Aufmacherbild: Portrait of Casual Man von Shutterstock / Urheberrecht: igor.stevanovic

[ header = Seite 2: Warum schon wieder ein Modell? ]

Warum schon wieder ein Modell?

Die Oberflächen in Businessanwendungen, aber auch in Tools sind häufig auf die Ein- und Ausgabe von Daten ausgerichtet. Typischerweise werden die Attribute einer oder mehrerer Entitäten in einer formularbasierten Oberfläche angezeigt (beispielsweise „Person“ oder „Bug Report“). Zu diesem Zweck werden formularbasierte Oberflächen benötigt, die die durch die Anwendung verwalteten Entitäten anzeigen und die verfügbaren Attribute einer oder mehrerer Entitäten zur Bearbeitung anbieten. Das manuelle Programmieren von solchen formularbasierten Oberflächen und besonders das Erstellen von Layouts sind aufwändig und erzeugen inhomogene Ergebnisse. Während der Kunde seine Anforderungen mit einfachen Konzepten wie Feldern, Spalten oder Attributgruppen spezifiziert, muss sich der Entwickler durch die mächtigen, aber auch komplexen Layoutmanager aktueller UI-Frameworks quälen. Da jede Anforderung erst langwierig umgesetzt werden muss, kann der Kunde erst spät Feedback geben – jede weitere Änderung kann eine erneute, aufwändige Entwicklung erfordern.

Bekannte UI-Editoren, wie beispielsweise Window Builder, ermöglichen zwar im Gegensatz zu handgeschriebenem Code ein früheres Feedback. Wer damit professionelle, skalierbare und vor allem funktionale Oberflächen erstellen will, wird früher oder später trotzdem den erzeugten Code erweitern und anpassen müssen. Insbesondere muss die entstehende Oberfläche meist noch manuell an Entitäten angebunden werden. Selbst implementierte Controls werden meist nicht unterstützt. Auch die in Businessanwendungen typischerweise geforderte Homogenität der Oberflächen stellen diese Ansätze nicht sicher. Am Ende erzeugt jede entstandene Zeile Code, egal ob geschrieben oder generiert, dauerhaft hohe Wartungskosten, insbesondere, wenn Änderungen am Layout gewünscht sind, die alle Formulare einer Anwendung betreffen.

Ziel der EMF Client Platform war es schon immer, den initialen Aufwand für das Erstellen von formularbasierten Oberflächen zu verringern. Sie erlaubt es, formularbasierte Oberflächen automatisch zu rendern, ohne eine Zeile Code zu schreiben. Die Oberflächen verbinden sich ohne manuelles Zutun mit den entsprechenden Entitäten und erlauben damit vom ersten Projekttag an die Ein- und Ausgabe und sogar Validierung von Daten. Diese Features werden im Abschnitt „Was bisher geschah“ im Detail beschrieben.

Neu ist nun die Möglichkeit, die generierten Oberflächen beliebig an eigene Layoutanforderungen anzupassen. Anpassungen am Layout der Oberflächen werden mit einem einfachen Modell ausgedrückt. Das Modell basiert auf einfachen, für Nutzer verständlichen Konzepten wie beispielsweise „Attributgruppe“ oder „Spalte“. Das Modell reduziert dabei die Komplexität der Layouttechnologien auf das benötigte Maß an Mächtigkeit. Die eigentlichen Formulare werden erst zur Laufzeit von einem Renderer gezeichnet. Dieser setzt die in der Anwendung unterstützten und erlaubten Layoutkonzepte zentral um und stellt damit die Homogenität der Oberfläche sicher. Werden in den Layoutkonzepten Änderungen notwendig, beispielsweise Zeilenabstände auf neue Bildschirme angepasst, ist lediglich der Renderer an zentraler Stelle anzupassen. Der modellbasierte Ansatz wird im Abschnitt „Modellbasierte Oberflächen“ beschrieben. Ein weiterer großer Vorteil des modellbasierten Ansatzes ist die Möglichkeit einer umfangreichen Toolunterstützung für den Entwickler der Oberfläche. Auszüge der Möglichkeiten stellen wir im Abschnitt „Tooling“ vor.

Die EMF Client Platform ist zwar ein Eclipse-Projekt, die formularbasierten Oberflächen lassen sich jedoch in beliebige Java-Anwendungen integrieren. Da die verwendeten Renderer austauschbar sind, können auch andere Oberflächentechnologien, wie beispielsweise JavaFX, unterstützt werden. Zusätzlich ist das Framework um eigene Komponenten, beispielsweise eigene Layoutkonzepte erweiterbar. Die Anbindungs- und Erweiterungsmöglichkeiten werden im letzten Abschnitt beschrieben.

[ header = Seite 3: Was bisher geschah ]

Was bisher geschah

Die EMF Client Platform unterstützte auch bisher schon die Entwicklung von formularbasierten Oberflächen. Da das neue Feature der modellbasierten Oberflächenentwicklung den bisherigen Ansatz erweitert, beschreibt dieser Abschnitt zunächst das Grundprinzip, nach dem die EMF Client Platform bisher – ohne das neue Feature – arbeitete. Leser, die damit bereits vertraut sind, können direkt zum folgenden Abschnitt springen.

Die EMF Client Platform kann ohne jedes Zutun eine formularbasierte Oberfläche für beliebige Entitäten erzeugen. Dazu macht sich die Plattform die Informationen zunutze, die im Datenmodell stecken. Dies liegt idealerweise als EMF-Modell vor, kann aber auch aus UML-Modellen oder dem XSD-Schema einer Datenbank erzeugt werden. Die Verwendung ist also nicht an eine bisherige Verwendung von EMF gebunden.

Das Datenmodell beschreibt die Entitäten, die mit der Anwendung verwaltet werden können. Das einfachste denkbare User Interface stellt alle als öffentlich markierten Attribute des Datenmodells in einem Formular dar und erlaubt dem Benutzer, diese Attribute in entsprechenden Controls zu bearbeiten. Technisch gesehen ist für eine solche erste und einfache Version einer formularbasierten Oberfläche außer dem Datenmodell selbst keine zusätzliche Information notwendig. Das Modell spezifiziert ja, welche Entitäten und welche zugehörigen Attribute es in der Anwendung gibt. Genau diese Information macht sich die EMF Client Platform für das Anzeigen von Entitäten in einem formularbasierten Editor zunutze. Im Folgenden soll der Ansatz anhand eines einfachen Beispiels vorgestellt werden. Das Beispiel definiert eine Entität „User“ mit folgenden drei Attributen:

  • First Name: String
  • Last Name: String
  • E-Mail-Adresse: Liste von Strings

 Das Beispiel ist bewusst einfach gehalten – der Ansatz spielt seine Stärken natürlich insbesondere bei einer großen Anzahl an Entitäten und Attributen voll aus.

Wird nun eine Entität vom Typ User, konkreter, eine Instanz der Java-Klasse User mit dem Editor der EMF Client Platform geöffnet, wertet dieser die Entität reflexiv zur Laufzeit aus und zeichnet eine erste Version einer formularbasierten Oberfläche (Abb. 1). Für die beiden String-Attribute wurde jeweils ein Textfeld und, links daneben, ein Label mit dem Attributnamen gerendert. Das dritte Attribut wird mit einem Multi-String Control angezeigt, das das Hinzufügen, Bearbeiten, Sortieren und Löschen von E-Mail-Adressen des Users erlaubt. Die Oberfläche ist bereits voll funktional. Das bedeutet: Änderungen werden in die Entität übertragen. Zu diesem Zweck wird jedes Control an ein oder mehrere Attribute automatisch angebunden. Die EMF Client Platform bietet für jeden einfachen Datentyp sowie für Referenzen ein entsprechendes Standard-Control an.

Abb. 1: Bereits ohne jegliche Zusatzinformationen kann die EMF Client Platform eine formularbasierte Oberfläche für eine Entität rendern

Diese erste Version der Oberfläche ist natürlich in den allermeisten Fällen nicht die endgültige Lösung. Die EMF Client Platform erlaubt sowohl die Anpassung der verwendeten Controls als auch des Layouts – siehe dazu die folgenden beiden Abschnitte. Die erste Version der Oberfläche, wenn auch noch nicht perfekt, bietet zwei entscheidende Vorteile: Sie erfordert nicht eine Zeile UI-Code und sie kann dem Kunden direkt nach der Definition der angezeigten Entitäten präsentiert werden. Ergeben sich daraus Änderungswünsche, entdeckt der Kunde beispielsweise ein fehlendes Attribut, kommt ein entscheidender Vorteil des Ansatzes zum Tragen: Durch das reflexive Auslesen der Informationen aus den Entitäten ist die EMF Client Platform robust gegen Änderungen. Soll nun beispielsweise auf Kundenwunsch der Entität User ein neues Attribut hinzugefügt werden, das in einer Enumeration das Geschlecht eines Users angibt, muss dieses lediglich der Entität, also dem Datenmodell, hinzugefügt werden. Nach einem erneuten Öffnen des formularbasierten Editors der EMF Client Platform ist das Attribut sichtbar (Abb. 2). Als Enumeration wird das Attribut mit einer Drop-down-Box gerendert. Wäre die Oberfläche hingegen manuell implementiert, wäre bei jeder Änderung an den Entitäten eine manuelle Anpassung aller Oberflächen notwendig gewesen, die die Entität anzeigen, und das, bevor sie durch den Kunden abschließend als sinnvoll beurteilt werden kann. Ist die Änderung am Ende doch unerwünscht, sind die entstandenen Kosten verloren.

Abb. 2: Neue Attribute werden ohne zusätzlichen Aufwand in der Oberfläche angezeigt

In Businessanwendungen müssen neben der reinen Anzeige und Bearbeitung von Attributen typischerweise die Eingaben des Benutzers validiert werden. Im Beispiel könnten die Attribute FirstName und LastName Pflichtfelder sein, die also zwingend die Eingabe eines Werts erfordern. Auch diese Anforderung kann initial ohne manuelle Entwicklungsschritte abgedeckt werden. Dazu muss allerdings die Information über die zu überprüfenden Regeln vorliegen. Ähnlich wie die Liste der verfügbaren Attribute ist die Information über den gültigen Wertebereich eines Attributs meist schon bei der Definition der Entitäten, beispielsweise in Form eines Datenbankschemas, festgelegt worden. Die EMF Client Platform kann auch diese Informationen auslesen und entsprechend nutzen. Gibt die Entität User aus dem Beispiel an, dass das Feld LastName nicht leer sein darf, zeigt das Text Control der EMF Client Platform bei leerer Angabe entsprechend einen Fehler an (Abb. 3).

Abb. 3: Die verwendeten Standard-Controls unterstützen eine Eingabevalidierung

Alle Standard-Controls können derartige Eingabevalidierungen anzeigen. Die EMF Client Platform liefert solche Controls für alle Grunddatentypen sowie für Referenzen bereits mit. In vielen Fällen wird man aber früher oder später zusätzlich eigene, stark angepasste Controls für bestimmte Attribute verwenden wollen.

Trotzdem muss nicht auf die Vorzüge des automatischen Aufbaus der Oberfläche verzichtet werden. Die EMF Client Platform unterstützt die Verwendung von eigenen Controls. Diese werden registriert und anschließend von den formularbasierten Oberflächen verwendet. Dabei kann genau angegeben werden, für welche Attribute ein bestimmtes, neues Control verwendet werden soll. Es lassen sich einfach Zuordnungen treffen, beispielsweise, dass ein eigenes Control für alle String-Attribute oder nur für ein ganz bestimmtes Attribut, zum Beispiel LastName, verwendet wird. Aber auch komplexe Regeln, etwa ein Control für Zahlenfelder länger als zehn Stellen, sind einfach zu realisieren.

Noch einfacher ist es in vielen Fällen, existierende Controls um fehlende Funktionen zu erweitern. Abbildung 4 zeigt eine solche Erweiterung. Neben dem Textfeld, das die E-Mail-Adresse anzeigt, wurde ein Button eingefügt, um direkt eine Mail zu versenden. Entsprechend registriert erscheint der Button neben allen E-Mail Attributen.

Abb. 4: Die EMF Client Platform erlaubt die Verwendung von eigenen und angepassten Controls

Auf diese Weise können in kleinen Schritten einzelne Controls erweitert oder ersetzt werden.

Die zentrale Verwaltung der Controls stellt sicher, dass einmal implementierte Controls leicht auffindbar bleiben und für alle gleich zu behandelnden Attribute wieder verwendet werden. Dies sorgt damit für ein homogenes Anwendungsbild und wenig zu wartenden Code. Das punktuelle Erweitern und Ersetzen von einzelnen Controls beschränkt den notwendigen Aufwand von Beginn nur auf die Änderungen, die wirklich notwendig sind. Für alle unangepassten Attribute sind weiterhin die Standard-Controls verfügbar. Das bedeutet, die Anwendung bleibt kontinuierlich benutz- und demonstrierbar. Selbst wenn bei Fertigstellung der Anwendung die meisten existierenden Controls durch eigenen Implementierungen ersetzt wurden, wird man keine Zeile Code entwickelt haben, die nicht ohnehin notwendig gewesen wäre. Im Gegenteil, durch die bessere Wiederverwendung von Controls und das vollständige Wegfallen des manuellen Layouts schrumpft die zu entwickelnde und zu pflegende Codebasis massiv. Weiterhin bleibt die Oberfläche robust gegen Änderungen an den Entitäten. Wird beispielsweise ein neues String-Attribut hinzugefügt, wird ohne weiteres Zutun das Control für String-Attribute gezeichnet, egal, ob es das Standard-Control oder ein eigenes ist.

Das bisher beschriebene Standardlayout, die einfache Liste an Attributen, wird allerdings auch in vielen Fällen nicht ausreichend für ein finales Produkt sein. Genau an diesem Punkt setzt das neue Feature der EMF Client Platform an: das Beschreiben des Layouts in einem eigenen Modell.

[ header = Seite 4: Modellbasierte Oberflächen ]

Modellbasierte Oberflächen

Durch den bisher beschriebenen Ansatz der EMF Client Platform ist es mit sehr wenig Aufwand und kaum manueller Entwicklung möglich, erste formbasierte Oberflächen zu erstellen. Diese stellen alle verfügbaren Attribute in einer Art Liste dar. Durch das Austauschen einzelner Controls kann das Aussehen und Verhalten einzelner Attribute angepasst werden. Damit bekommt der Kunde eines Projekts bereits einen sehr guten Eindruck der laufenden Anwendung und kann sie sogar schon benutzen. Trotzdem wird es in den meisten Projekten recht bald die Anforderung nach einem angepassten, komplexeren Layout geben, das die einfache Liste an Controls ersetzt. Das ist typischerweise der Zeitpunkt, ab dem sich ein Entwickler mit vielen Zeilen Code durch die Verwendung von Layoutmanagern, vertikalen Ausdehnungen, maximalen Höhen und relativen Positionen quälen muss. Und das alles oft nur, damit der Kunde nach einer Demonstration am Ende doch alles ganz anders haben möchte. Außerdem geht durch die manuelle Implementierung des Layouts die Robustheit gegen Änderungen verloren, da jedes Control manuell einen expliziten Platz im Layout zugewiesen bekommt.

Mit dem neuen Feature der Modellierung von Oberflächen geht die EMF Client Platform hier nun einen radikal anderen Weg. Der Ansatz verzichtet selbst für das finale Layout vollständig auf manuellen Code. Stattdessen werden die Layoutinformationen in einem einfachen Modell spezifiziert, das den gewünschten Aufbau der Oberfläche beschreibt. Ein View-Modell besteht aus Layoutinformationen, sowie aus Controls selbst, die an bestimmter Stelle im Layout platziert werden. Controls sind an bestimmte Attribute aus dem Datenmodell angebunden und erlauben deren Ein- und Ausgabe.

Die Erstellung des Modells wird von einem leicht zu verwendendem Tool unterstützt. Das fertige Modell wird schließlich zur Laufzeit von einem Renderer interpretiert. Ein sehr einfaches Beispiel für ein Layout ist das bereits zuvor beschriebene Listenlayout, in dem jedes Control in einer eigenen Zeile dargestellt wird. Das Layout ist zwar wie zuvor beschrieben ohne jeglichen Zusatzschritt bereits automatisch verfügbar; im Folgenden wird jedoch als erstes einfaches Beispiel beschrieben, wie genau dieses Layout modellbasiert ausgedrückt werden kann. Für die Darstellung von Elementen in einer vertikalen Liste unterstützt das UI-Modell das Element VerticalLayout. Das Layout stellt alle enthaltenen Elemente untereinander als Zeilen dar. Die enthaltenen Elemente sind in diesem einfachen Beispiel direkt die gewünschten Controls.

Die EMF Client Platform bietet einen Editor für die IDE an, mit dem das Modell der Oberfläche komfortabel bearbeitet werden kann. Mehr dazu im folgenden Abschnitt „Tooling“. Ein View-Modell besteht immer aus einem Root-Knoten (View), der per Kontextmenü mit Unterelementen befüllt wird. Abbildung 5 zeigt das Modell, das das bisher automatisch erstellte Layout explizit ausdrückt. Wie in der Abbildung zu erkennen, kann das Modell bereits in der IDE live in einem Preview gerendert werden. Dadurch sieht der Oberflächendesigner direkt, welches Ergebnis er zu erwarten hat, ohne die Anwendung dazu erst starten zu müssen. Dieses frühe Feedback vereinfacht das Erstellen eines korrekten Layouts zusätzlich.

Abb. 5: Modelleditor: Links das Modell (nicht für den User sichtbar) und rechts die resultierende Oberfläche

Das so erstellte View-Modell (Layout) wird nun als Datei abgespeichert und mit der Anwendung ausgeliefert. Die Datei ist einem bestimmten Typ von Entität zugeordnet. Zur Laufzeit liest der Editor der EMF Client Platform beim Öffnen einer Entität die Datei ein und rendert die Oberfläche entsprechend. Ist für eine Entität kein View-Modell angegeben, wird weiterhin das Default-Layout verwendet. Das Layout der Oberflächen kann also in kleinen Schritten iterativ spezifiziert werden.

Das bisher beschriebene Modell ist ein sehr einfaches Beispiel, so einfach, dass es die EMF Client Platform, wie im ersten Abschnitt beschrieben, ohne das Zutun eines Designers automatisch selbst erzeugen konnte. Durch den modellbasierten Ansatz lässt sich dieses Modell nun aber einfach verfeinern und damit ein besser angepasstes Oberflächenlayout erstellen. Im bisherigen Layout wird gerade auf breiten Bildschirmen viel Platz verschwendet. Eine einfache Möglichkeit, den Platz besser zu nutzen, wäre, nicht nur eine, sondern zwei vertikale Reihen als parallele Spalten aufzubauen. In diesem Layout (Abb. 6) gibt es also zwei VerticalLayout-Elemente. Da diese beiden Container horizontal nebeneinander angeordnet werden, sind sie in einem HorizontalLayout enthalten, das alle Kind-Elemente nebeneinander darstellt.

Abb. 6: Das Layout kann iterativ verfeinert werden, durch die hierarchische Ansicht bleiben auch komplexe Definitionen gut verständlich, oben das Modell (nicht für den User sichtbar), unten die resultierende Oberfläche

Auch das zweite Beispiel ist im Vergleich zu den Formularen echter Businessanwendungen immer noch sehr einfach gehalten. Natürlich existieren neben den beiden beschriebenen Layouttypen weitere Layouts (z. B. GridLayout) sowie Layoutelemente (z.  B. Separators). Weiterhin können Layouts mit Labeln und Rahmen versehen werden, die bestimmte Gruppen an Attributen kennzeichnen. Durch den modellbasierten Ansatz behält man auch komplexe Layouts gut im Griff. Unterstützt wird man dabei zusätzlich von Tooling.

[ header = Seite 5: Tooling ]

Tooling

Der modellbasierte Ansatz, ein Layout zu erstellen, ist nicht nur einfacher und effektiver. Durch das bessere Abstraktionsniveau ist es, anders als in technologieabhängigem Sourcecode, möglich, nützliches Tooling bereitzustellen. Ein Beispiel dafür ist die bereits beschriebene Preview, die das aktuelle Layout live anzeigt, ohne dafür die gesamte Anwendung starten zu müssen. Aber auch bei der Modellierung selbst gibt es Unterstützung. Es wäre beispielsweise recht viel manueller Aufwand, für viele Attribute manuell Controls an einer bestimmten Stelle im bestehenden Layout zu erzeugen, die diese in der Oberfläche repräsentieren. Da die verfügbaren Attribute jedoch bekannt sind, bietet das Tooling der EMF Client Platform einen Wizard an, mit dem in einem ausgewählten Container alle in einer Checkbox angebotenen Attribute als Controls erzeugt werden. Dabei lassen sich auch bereits vorhandene Controls ausblenden. Meistens soll ja ein Attribut nur einmal pro Formular angeboten werden. In dem vorher beschriebenen, zweispaltigen Layout lassen sich so beispielsweise zunächst per Auswahl die Attribute für die erste Spalte erzeugen und anschließend mit einem Klick alle weiteren in die zweite Spalte platzieren. Im Anschluss lässt sich die Aufteilung natürlich leicht per Drag and Drop korrigieren. Schlussendlich lässt sich per Mausklick sogar validieren, ob alle Attribute ihren Platz im Layout gefunden haben. Gerade bei einer großen Anzahl von Attributen ist eine manuelle Überprüfung auf Vollständigkeit sonst mühsam. Die Überprüfung ist insbesondere bei Änderungen an den Entitäten nützlich, wenn also potenziell neue Attribute hinzugekommen sind, die erst noch platziert werden müssen.

Gerade bei Änderungen an Entitäten wird auch klar, dass die Robustheit der automatisch berechneten Lösung eingeschränkt wird, sobald ein explizites Layout angegeben wird. Neue Attribute werden nicht mehr ohne weiteres Zutun in die Oberfläche aufgenommen. Umgekehrt ist das nach Erstellung eines expliziten Layouts auch meistens nicht mehr wünschenswert. Neue Attribute müssen ja einen passenden Platz zugewiesen bekommen. Es gibt allerdings gerade für frühere Phasen eines Projekts, in denen noch viele Änderungen auftreten, aber schon erste Layouts definiert sind, eine sinnvolle Zwischenlösung. Die EMF Client Platform bietet eine Schnittstelle für das so genannte Postprocessing von View-Modellen an. Ein bereits mitgelieferter Processor untersucht auf Wunsch ein existierendes Layout. Alle noch nicht explizit im Layout platzierten Attribute werden unten an das Layout angefügt. Dort sind sie zunächst einmal ohne weiteres Zutun sofort sicht- und benutzbar, bis sie ihren expliziten Platz im Layout erhalten.

Nicht zuletzt ist es auch möglich, programmatisch auf das View-Modell zuzugreifen, beispielsweise mit der eben beschriebenen Processor-Schnittstelle. Die Komplexität des dazu verwendeten API folgt dabei der des entsprechenden Toolings; sie ist immer noch deutlich einfacher zu benutzen als die Layoutmanager typischer UI-Frameworks. So lässt sich beispielsweise der gerade beschriebene Processor so erweitern, dass er ein zweispaltiges Layout automatisch gleichmäßig mit Attributen auffüllt.

[ header = Seite 6: Anpassung und Einbindung ]

Anpassung und Einbindung

Das beschriebene Feature ist Teil des Open-Source-Frameworks EMF Client Platform. Alle beschriebenen Kernkonzepte, Renderer-Implementierungen für SWT und für die Webanwendungstechnologie RAP sowie die Anbindung von EMF-Objekten als Entitäten sind Open Source unter der Eclipse Public License verfügbar und damit bestens für eine kommerzielle Verwendung geeignet. Die entstehenden Oberflächen lassen sich an beliebiger Stelle in die eigene Anwendung integrieren. Dazu lassen sich automatisch erstellte oder modellierte Oberflächen in eigene Fenster, als Teil von Master-Detailansichten oder eingebettet in Webseiten, rendern. Die EMF Client Platform stellt dafür entsprechende Schnittstellen bereit.

Das Framework ist bewusst sehr modular aufgebaut und bietet zahlreiche Anpassungsmöglichkeiten. So lassen sich beispielsweise die existierenden Renderer erweitern und anpassen. Damit kann das aus den View-Modellen gerenderte Layout vollständig auf das im eigenen Projekt gewünschte Look and Feel angepasst werden. Ändern sich die Anforderungen an das Aussehen der Anwendung, beispielsweise durch neue Endgeräte, ist lediglich der zentrale Renderer anzupassen.

Abgesehen vom Renderer selbst wird der Entwickler vollständig von der Aufgabe des manuellen Layoutings befreit. Gleichzeitig wird durch den zentralen Renderer ein anwendungsweites homogenes Layout sichergestellt. Dieses kann sogar durch eigene Validierungen auf dem View-Modell sichergestellt werden, beispielsweise, indem eine maximale Spaltenzahl für Formulare definiert wird.

Weiterhin lassen sich leicht neue Renderer hinzufügen, etwa für JavaFX, für Swing oder gar für ein proprietäres Endgerät. Einige Renderer befinden sich bereits in der Entwicklung, eine Anfrage bei den Projektentwicklern lohnt sich also. Das View-Modell selbst ist dabei unabhängig vom eigentlichen Renderer, es ist also möglich, das gleiche Layout für technisch unterschiedliche Oberflächen zu verwenden. Die Umsetzung eines Renderers ist deutlich weniger Aufwand als man denken möchte, insbesondere, wenn Vorerfahrungen mit bereits implementierten Renderern existieren. Alle Konzepte werden nur genau einmal implementiert. Mögliche Layoutfehler können zentral behoben werden. In der Praxis zahlt sich selbst die vollständige Implementierung eines neuen Renderers bereits nach wenigen erstellten Oberflächen im Vergleich zur manuellen Implementierung aus.

Nicht zuletzt ist es häufig sinnvoll, ein existierendes View-Modell anzupassen, zu erweitern oder sogar zu ersetzen. Das liegt im Wesentlichen in der Tatsache begründet, dass es für die Modellierung von Oberflächen keinen Universalansatz geben kann, der für alle Projekte perfekt geeignet ist. Der beschriebene Ansatz vereinfacht das Erstellen von Oberflächen enorm – zum einen durch besseres Tooling und die Render-Architektur, zum anderen aber auch ganz bewusst durch die Einschränkung von Möglichkeiten und damit die Verringerung der Komplexität. Damit das gut funktioniert, müssen die Möglichkeiten idealerweise genau den in einem Projekt benötigten Konzepten entsprechen.

Kunden definieren ihre Anforderungen an die Oberfläche typischerweise nicht in Begriffen wie GridLayout oder VerticalSpan, sondern in für jedermann verständlichen Konzepten wie „Gruppen“ oder „Zeilen“. Die im UI-Modell benötigten Konzepte unterscheiden sich natürlich von Projekt zu Projekt. Das gilt zum einen für die benötigte Mächtigkeit, also beispielsweise, welche Layoutarten unterstützt werden müssen. Zum anderen kann das aber auch die Art der Modellierung betreffen, also beispielsweise die Namen bestimmter Elemente oder deren Zusammenspiel. Die optimale Lösung hängt dabei sehr davon ab, welche Zielgruppe das UI-Modell am Ende nutzt, um die Oberflächen zu designen. Während Programmierer Konzepte wie „Horizontal Layout“ leicht verstehen, kann die Fachabteilung mit „Horizontal Attribute Group“ möglicherweise deutlich mehr anfangen. Wird das View-Modell am Ende gar so gewählt, dass es der Kunde selbst verwenden kann, ist eine maximale Verkürzung der Feedbackschleife gelungen.

Da es sich bei der vorgestellten Implementierung um ein leicht erweiterbares Framework handelt, das im Kern vollständig aus Open-Source-Komponenten besteht, können alle beschriebenen Anpassungen effektiv durchgeführt werden. Dienstleister haben sich bereits auf genau diese Anpassungen spezialisiert und verfügen über entsprechende Erfahrungen aus verschiedenen Projekten. Gerade bei der Umsetzung oder Anpassung von View-Modellen und Renderern können Projekte hier von Querschnittserfahrungen profitieren.

[ header = Seite 7: Fazit ]

Fazit

Mit der EMF Client Platform konnten bisher schon formularbasierte Oberflächen effektiv und ohne zusätzliches Coding basierend auf einem Datenmodell erstellt werden. Diese waren und sind robust gegen Änderungen an den Entitäten, beispielsweise beim Einführen neuer Attribute. Außerdem konnten die Oberflächen durch eigene, angepasste Controls angepasst werden. Das neue Feature der modellbasierten Beschreibung von Layouts eröffnet nun völlig neue Möglichkeiten. Anstatt sich durch die komplexen Layoutmanager verschiedenen UI-Technologien zu quälen, werden Layouts toolunterstützt in einem speziell für diesen Zweck entwickelten View-Modell ausgedrückt. Das Modell wird zur Laufzeit von einem Renderer interpretiert. Der Ansatz verringert den Aufwand und sorgt für sehr kurze Feedbackschleifen. Die Anwendung bleibt kontinuierlich demonstrier- und benutzbar. Weiterhin stellt das Vorgehen die Homogenität der Oberfläche sicher und verringert massiv die zu wartenden Zeilen Code. Einzelne Teile des Frameworks, wie verwendete Controls, das View-Modell und die verfügbaren Renderer, sind erweiter- und austauschbar. Damit ist das Framework auf beinahe beliebige Technologien und Einsatzszenarien übertragbar. Nicht zuletzt ist die Beschreibung der Oberflächen durch das Modell unabhängig von einer konkreten Oberflächentechnologie. Anwendungen können damit durch einen Austausch des Renderers migriert werden, beispielsweise von SWT auf JavaFX.

Letztendlich ist der Ansatz natürlich keine Allzweckwaffe. Vielmehr spielt er seine Stärken in einem klar definierten Umfeld aus: Businessanwendung und Tools mit homogen zu gestaltenden Formularen zur Ein- und Ausgabe von Daten. In diesem Szenario zeigen sich durch den schnellen Einstieg und die iterative Vorgehensweise sehr früh spürbare Vorteile. Eine ausführliche Schritt-für-Schritt-Anleitung, um den Ansatz selbst auszuprobieren, findet sich unter [1]. Das Feature ist ab dem Milestone 1 der Version 1.1.0 verfügbar.

Geschrieben von
Jonas Helming
Jonas Helming
Dr. Jonas Helming ist Geschäftsführer der EclipseSource München GmbH sowie Consultant, Trainer und Software Engineer im Bereich Eclipse-Technologie. Seine Schwerpunkte liegen neben Java auf den Technologien Eclipse RCP, Eclipse-Modellierung und Eclipse 4. Weiterhin verfügt er über mehrjährige Erfahrung in der Etablierung und Anwendung von agilen Prozessen. Jonas ist aktives Mitglied der Eclipse-Community, leitet mit der EMF Client Plattform und dem EMFStore zwei bei der Eclipse Foundation gehostete Open-Source-Projekte und ist in einigen weiteren aktiv beteiligt. Als Berater und Trainer verfügt er über mehrjährige Erfahrung in der Vermittlung von Themen rund um Java und Eclipse sowie agilen Prozessen und hält einen Lehrauftrag der Technischen Universität München. Darüber hinaus ist er als Speaker regelmäßig auf Kernkonferenzen wie der JAX oder der EclipseCon. Kontakt: jhelming@eclipsesource.com
Maximilian Kögel
Maximilian Kögel
Dr. Maximilian Kögel ist Geschäftsführer der EclipseSource München GmbH und arbeitet als Senior Software Architect im Bereich Eclipse- und Web-Technologie. Neben seiner Fokussierung auf das Eclipse Modeling Framework und Eclipse RCP ist er auch mit der Entwicklung von Webapplikationen mit AngularJS, Web Components und JSON Schema vertraut. Ein Kernthema seiner Arbeit ist das Erstellen von Modellierungswerkzeugen basierend sowohl auf einem Eclipse- als auch einem Web Technologiestack. Er ist ein aktives Mitglied der Eclipse-Community, regelmäßiger Sprecher auf EclipseCons, Leiter und Committer bei mehreren Eclipse Projekten, u.a. EMFForms und EMF Core und nicht zuletzt Mitglied im Eclipse Architecture Council. Auch außerhalb des Eclipse Ökosystems ist er in Open-Source-Projekten aktiv und leitet z.B. das JSONForms-Projekt zur Entwicklung von Web-Applikationen. Als Berater und Trainer verfügt er über langjährige Erfahrung in der Anwendung und Vermittlung von Expertenwissen rund um Java, Eclipse und Web-Technologien sowie agilen Prozessen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: