Kapitel 5. Klassen- und Funktionsüberblick

In komplexeren Anwendungen ist es oft sinnvoll, mehr als einen Kontext zu nutzen. Diese können entweder unabhängig voneinander sein oder Zugriff auf die Elemente anderer Kontexte haben. Wie die Sichtbarkeit festgelegt werden kann, wird weiter unten erläutert.

Instanzen von Context sind stets einer GUI-Komponente zugeordnet. Da die grafische Benutzeroberfläche eine Objekthierarchie bildet, unterstützen auch Kontexte die hierarchische Anordnung. Soll der im Beispiel beschriebenen Oberfläche ein weiterer Viewer hinzugefügt werden, der eine eigene Werkzeugleiste mitbringt und von den anderen Komponenten unabhängig ist, kann zu diesem Zweck ein weiterer, unabhängiger Kontext angelegt werden, der lediglich dem zweiten Viewer und seiner Werkzeugleiste zugeordnet wird.

Es ist nicht zwingend notwendig, jedes GUI-Element mit einem eigenen Kontext zu versehen. Vielmehr wird zusammengehörigen Elementen ein gemeinsamer Kontext zugewiesen. Hat eine Oberflächenkomponente keinen ihr eigens zugewiesenen Kontext, wird jenes Context-Objekt verwendet, das bei Durchsuchen der Komponentenhierarchie zur Wurzel hin als erstes auftaucht. Für weniger komplexe Benutzeroberflächen genügt es somit, einen einzigen Kontext für die RootPane des beinhaltenden Fensters zu registrieren.

In umfangreicheren Benutzeroberflächen ist es häufig der Fall, dass nur Teile der gesamten Applikation gleichzeitig sichtbar sind. Dieser Zustand tritt beispielsweise dann ein, wenn JTabbedPanes zur Präsentation verwendet werden: Sämtliche GUI-Elemente, die sich auf ausgeblendeten Tabs befinden, sind inaktiv. Die Implementierung von Context unterstützt dieses Konzept, indem auch jeder einzelne Kontext aktiv oder inaktiv gesetzt werden kann. Auf einer gegebenen Instanz geschieht dies über die Methode setActive(boolean active). Im Regelfall muss dieser Aufruf manuell erfolgen. Die häufig verwendeten Komponententypen JTabbedPane sowie JDesktopPane bilden jedoch eine Ausnahme, da die Aktivierung ihnen zugeordneter Kontexte durch das Framework automatisch vorgenommen wird.

Notwendig wird die Funktion zur Deaktivierung von Kontexten dort, wo eine Kontexthierarchie existiert, in der die einzelnen Context-Objekte nicht unabhängig voneinander sind.

Die Abhängigkeit einzelner Context-Objekte voneinander und damit auch die Sichtbarkeit von Kontextinhalten innerhalb der Hierarchie wird über sogenannte Aggregationsregeln gesteuert, die bei der Erstellung des Kontexts angegeben werden. Wird ein Context nach dem in ihm enthaltenen Argumenten befragt, so werden zunächst die Argumente, die dem betreffenden Context selbst hinzugefügt wurden, geliefert. Darüber hinaus können aber auch Argumente von über- oder untergeordneten Kontexten sichtbar werden. Die Sichbarkeitsangaben werden gesteuert über die Werte der Enumerationen Context.Ancestors und Context.Children. Folgende Aggregationsregeln sind möglich:

Die Verwaltung der Kontexte erfolgt mittels folgender Methoden:

Instanzen der Klasse Context informieren registrierte Interessenten (ContextListener) über Änderungen des Kontexts. Dies betrifft Änderungen an den enthaltenen Objekten, aber auch semantische Änderungen des Kontexts, die provoziert werden können durch einen Aufruf der Methode contextChanged().

In manchen Fällen ist es notwendig, auf die Objekte eines Kontexts gezielt zuzugreifen. Die Klasse ContextUtils bietet zu diesem Zweck eine Sammlung statischer Hilfsmethoden, die folgende Aufgaben erfüllen:

Die meisten Methoden existieren in zwei Ausprägungen. Die erste akzeptiert ein Context-Objekt auf dem die gewünschte Operation ausgeführt wird. Der zweiten wird eine JComponent übergeben. In diesem Fall wird der gültige Kontext automatisch identifiziert und für die Ausführung der Operation verwendet.

Die Parameter-Injection bezieht sich auf Konfigurationswerte, die aus den commands.properties stammen. Um einen Parameterwert zur Verfügung zu stellen, sind folgende Schritte notwendig:

Für Parameter, die auf diese Weise angefordert werden, stellt das Framework sicher, dass diese nach Instanziierung der Klasse bereitstehen.

Für Fälle, in denen der Parametername in commands.properties nicht aus dem Methodennamen generiert werden soll, besteht die Möglichkeit, die Annotation @Parameter mit einem optionalen Argument name zu versehen, das den in der Properties-Datei verwendeten Namen definiert. Des Weiteren existiert ein Annotations-Argument optional, mit dem definiert werden kann, dass das Fehlen der Parameter-Definition in commands.properties nicht zu einem Fehler führen soll. Das Kommando wird dann trotzdem instanziiert und annotierte Felder behalten ihren in der Klasse definierten Default-Wert.

Die Parameter-Injection funktioniert für folgende Datentypen: String, Color, enums und die primitiven Datentypen.

Die zweite Möglichkeit ist die Argument-Injection. Während Parameter aus den Properties stammen, beziehen sich Argumente auf im Context vorhandene Objekte und werden aus diesem heraus zur Verfügung gestellt.

Das Anfordern von Objekten aus dem Kontext geschieht (analog zur Parameter-Injektion) durch Anbringen der Java-Annotation Argument an einer setter Methode. Das Framework führt einen Aufruf der Methode mit dem ersten im Kontext gefundenen Objekt des entsprechenden Typs durch. Dies geschieht vor einem später eventuell erfolgenden Aufruf der execute()-Methode.

In realen Szenarien kann es leicht vorkommen, dass der Kontext mehrere Objekte desselben Typs enthält. Anstatt einfach das erste Objekt des gewünschten Typs anzufordern, besteht alternativ dazu die Möglichkeit, sämtliche Objekte eines Typs abzufragen. In diesem Fall werden alle gefundenen Objekte in einer Collection des entsprechenden Typs zurückgegeben. So werden beispielsweise mit dem Code-Fragment

@Argument
public void setSomeStrings(Collection<String> allContextStrings){…};

sämtliche String-Instanzen aus dem Kontext angefordert und injiziert.

In Zusammenhang mit Collections existiert eine Einschränkung der InjectedCommands: Es ist nicht möglich, Objekte des Typs Collection im Kontext abzulegen und mittels Argument-Injection auszulesen. Grund hierfür ist die Generic Type Erasure: Zur Laufzeit sind die durch Generics spezifizierten Typinformationen nicht vorhanden, sodass eine korrekte Typkonvertierung nicht zuverlässig möglich ist. Soll eine Ansammlung von Objekten im Kontext abgelegt und injiziert werden, so empfehlen wir dafür ein dediziertes Fachobjekt zu erstellen, das die Objektmenge vorhält.

Die Annotation @Argument bietet verschiedene Optionen an, die den Injektions-Vorgang beeinflussen können. Wie es schon für Parameter der Fall war, können auch Argumente als optional markiert werden. Des Weiteren existiert eine Option boolean allowOtherMatches, die festlegt, ob bei der Abfrage nach einem einzelnen Objekt das Vorhandensein mehrerer gleicher Objekttypen zu einem Fehler führen soll. Die Option boolean matchSubclasses legt fest, ob bei der Suche nach Objekten im Kontext auch Subtypen des angeforderten Typs zurückgeliefert werden sollen. Eine letzte Option, Class<? extends Object> match, definiert nach welchem Objekttyp der Kontext durchsucht werden soll. Wie aus dem Beispiel bereits hervorging, wird der gewünschte Typ im Regelfall automatisch erkannt. Dieses zusätzliche Attribut erlaubt es jedoch, eine nähere Einschränkung – zum Beispiel auf eine bestimmte Subklasse – zu treffen.

Eine letzte Möglichkeit der Argument-Injizierung bietet die Annotation @AllArguments. Diese stellt sämtliche Argumente des Kontextes zur Verfügung. Im Regelfall geschieht dies über einen Rückgabewert des Typs Collection<Object>, wobei zu bedenken ist, dass die Klasse Context das Interface Collection implementiert. Man bekommt daher eigentlich eine Instanz von Context zurück. Um an dieser Stelle keine manuellen Typ-Checks und -Konvertierungen durchführen zu müssen, kann auf der Annotation @AllArguments die Option match = Context.class spezifiziert werden. Ist diese Option vorhanden, so wird direkt eine Instanz von Context zurückgegeben.