PartMaster

Im Teil 5 Wiederverwendbarkeit des leichtgewichtigen Controllers dieser Serie wurde die einfache Wiederverwendbarkeit eines nach dem hier vorgestellten Ansatz umgesetzten Controllers illustriert. In diesem Teil wird es darum gehen, was es eigentlich noch braucht, um den Ansatz in einem realen Projekt nutzen zu können.

Widget-Properties

Aus dem Listing für das View-Interface ObservableClockView lässt sich erahnen, dass durch unüberlegte Anwendung des Ansatzes leicht aufgeblähte Schnittstellen entstehen können, denn für jedes SWT-Control müssen alle einzelnen relevanten Properties (im konkreten Fall z.B. die Properties selection, und text des mode-Button-Controls und die Properties enabled, und text des time-Text-Controls) im View-Interface für den Controller zugreifbar gemacht werden. Hier bietet sich die Erstellung und Nutzung einer Convenience-Schicht an, in welcher Interfaces und Klassen zur Verfügung gestellt werden, die solche zusammengehörigen Properties eines Controls bündeln. Beispiele für solche Convenience-Interfaces sind in den Listings 16 und 17 dargestellt.

package de.partmaster.databinding.observable.ui.core.widget;

public interface ObservableButton {

	IObservableValue getText();
	IObservableValue getSelection();
	...
}

Listing 16: Convenience-Interface für die Properties eines Button-Controls

package de.partmaster.databinding.observable.ui.core.widget;

public interface ObservableButton {

	IObservableValue getText();
	IObservableValue getEnabled();
	...
}

Listing 17: Convenience-Interface für die Properties eines Text-Controls

Listing 18 zeigt, wie sich das View-Interface ObserveableClockView aus Listing 8 unter Verwendung von Convenience-Interfaces vereinfachen lässt.

package de.partmaster.databinding.observable.ui.sample;

import org.eclipse.core.databinding.observable.value.IObservableValue;

public interface ObservableClockView {

	ObservableButton getMode();
	ObservableText getTime();
	...
}

Listing 18: Vereinfachung des View-Interface ObservableClockView durch Convenience-Interfaces für die Control-Properties

Viewer

Das Problem einer großen Properties-Anzahl trifft in noch stärkerem Maße auf die komplexeren Viewer-Klassen z.B. für die Tabellen- und Baumdarstellung zu, wo neben den einfachen Properties auch noch Label- und Content-Provider in einer von ihren schwergewichtigen Abhängigkeiten abstrahierten Form für den Controller zugreifbar gemacht werden müssen. Eine erweiterte Observables-Schicht muss für den Controller eine Möglichkeit bereitsstellen, zu können.

Event-Listener

Obwohl das Data Binding viele Listener an View- (und Model-) Events für den Controller kapselt, bleiben trotzdem noch View-Events übrig die ein Controller Listener an- und abmelden können muss (z.B. ActionListner an Buttons). Eine erweiterte Observables-Schicht muss für den Controller eine Möglichkeit bereitsstellen, Listener für GUI-Events bei der View an- und abmelden zu können.

UFaceKit und Riena

In anderen Projekten wurden bereits Lösungen für GUI-unabhängigen Schnittstellen für Viewer und Listener entwickelt:

• Im Eclipse Projekt Riena (http://www.eclipse.org/riena/) heißen die Wrapper Ridgets. Ein Nachteil der Ridgets besteht meines Erachtens darin, dass die neutrale Fassade für die Label- und Content-Provider auf JavaBean-Properties aufbaut und damit die Kodier- und Debug-Probleme einer auf Reflection basierenden Architektur mit sich bringt. Mit der in Eclipse 3.5 eingeführten Data Binding Properties API steht mittlerweile eine bessere Alternative gegenüber den JavaBeans-Properties zur Verfügung. Bei herkömmlichen JavaBeans wird die Data Binding Properties API zwar ebenfalls auf Java-Reflection-Mechanismen abgebildet, aber bei EMF-basierten Datenmodellen oder den UBeans aus dem Projekt UFaceKit nicht.
• Im bereits erwähnten Eclipse Incubations Projekt UFaceKit wird der Ansatz verfolgt, komplette GUI-Toolkits mit einer neutralen Fassade zu versehen, so dass nicht nur die Integration mit dem Controller sondern die gesamte Implementierung der View-Klassen unabhängig vom zugrunde liegenden GUI-Toolkit bleibt. Das ambitionierte Ziel einer kompletten Kapselung has aber auch Nachteile: Tools und Know-how für das native GUI-Toolkit sind nur noch eingeschränkt nutzbar. Im Gegensatz dazu erfolgt nach dem hier vorgestellten Ansatz die gesamte Implementierung der View auf Basis der nativen API. Nur die Kopplung der View mit dem Controller verändert sich.

(Zwischen-)Fazit

In dieser Serie wurde ein Ansatz vorgestellt, wie sich in einer Model-View-Controller-Architektur mit Abhängigkeiten der Controller-Schicht von schwergewichtigen GUI- und Modell-Komponenten Hilfe des Eclipse Data Binding Frameworks vermeiden lassen. Dadurch können die Controller so gestaltet werden, dass sie einfach testbar und gut wiederverwendbar sind. Die Umsetzung des Ansatz ist schnell erklärt:
»Benutze eine Observable-Factory aus dem Eclipse Data Binding Framework nur dort, wo sowieso schon die schwergewichtigen Abhängigkeiten bestehen, die diese konkrete Observable-Factory mit sich bringt, auch wenn dadurch an dieser Stelle eine neue leichtgewichtige Abhängigleit vom Data Binding Core erzeugt wird.«
Die Herausforderung um den Ansatzes für praktische GUI-Projekte einsetzbar zu machen, ist die Entwicklung einer Abstraktionsschicht für die Event-Listener und Viewer als Erweiterung der Interfaces aus dem Eclipse Data Binding.