GWT im Einsatz

Robert Hanson, Adam Tacy

GWT im Einsatz

2007

567 Seiten

Format: PDF, Online Lesen

E-Book: €  39,99

E-Book kaufen

E-Book kaufen

ISBN: 9783446414068

 

9 Eine Anwendung modularisieren (S. 295-296)

Dieses Kapitel
behandelt die Konfiguration von GWT-Modulen,
erklärt das Einbinden externer Module,
beschreibt das Injizieren von CSS und JavaScript,
stellt das Packen von Modulen zu JAR-Dateien dar.


Nachdem Sie alle Komponenten für die Benutzeroberfläche erstellt haben, wollen wir nun damit beginnen, die Anwendung zu modularisieren. Ein Grundprinzip der Softwareentwicklung, das seit den 1960er-Jahren Gültigkeit hat, ist die Möglichkeit, Code in modularer Form zu entwickeln, um die Sicherheit und Wiederverwendbarkeit zu steigern. GWT unterstützt die modulare Entwicklung auf zweierlei Weise: Da Sie eine Java-Anwendung erstellen, haben Sie Zugriff auf alle Wohltaten der Java-eigenen Package-Struktur. Zweitens – das ist in GWT neu – gibt es das Konzept der XML-Module. Zwischen GWTModulen und Java-Packages besteht bis zu einem gewissen Grad ein synergistisches Zusammenwirken, aber trotzdem sind sie nicht dasselbe. Das Vorhandensein eines Java- Packages in Ihrem Klassenpfad bedeutet nicht automatisch, dass Ersteres für den GWTCompiler auch sichtbar ist. Keine Sorge: Weil dieses Thema eine Quelle der Verwirrung ist, behandeln wir den Sachverhalt im vorliegenden Kapitel.

Definition

Ein Modul ist eine logische Sammlung von Klassen und Ressourcendefinitionen, deren Verwaltung als Einheit sinnvoll ist.

Bislang haben Sie die Anwendung Dashboard wahrscheinlich als eine umfangreiche Softwareeinheit aufgefasst – eine Annahme, die durchaus zutreffend ist, ebenso gilt aber, dass sich eine Anwendung aus einer Anzahl von Modulen zusammensetzen kann und jedes dieser Module in einer Modul-XML-Datei definiert ist, die zudem eine Reihe ressourcenspezifischer Elemente definiert. Das Dashboard bietet sich naturgemäß zur Modularisierung an, da es eine Hauptanwendung und eine ganze Reihe von Komponentenanwendungen umfasst.

9.1 Modularisierungsstruktur erstellen

Wir erwähnten bereits, dass zwischen den GWT-Modulen und der Package-Struktur von Java eine Art Synergie besteht: Sie sind einander ähnlich, aber doch unterschiedlich. Ein Java-Package besteht aus einer Anzahl von Klassen, die – benutzerfreundlich – im selben Verzeichnis abgelegt sind. Ein GWT-Modul besteht aus einem Satz von Konfigurationsdaten, die sich auf ein bestimmtes GWT-Projekt beziehen. Es enthält Eintrittspunkte (sofern vorhanden), Verweise auf Stylesheets, andere Module, auf die dieses Modul angewiesen ist usw. All dies behandeln wir in Abschnitt 9.3, wo wir die Modularisierung des Dashboards beschreiben.

Ein warnendes Wort: Es ist nicht ungewöhnlich, dass sich ein Satz von Java-Packages auf ein bestimmtes Projekt bezieht – und damit auch auf ein GWT-Modul. So könnte man fälschlicherweise durchaus annehmen, dass ein GWT-Modul das Gleiche wie ein Satz Java-Packages darstellt, weil dies nicht immer der Fall sein muss. Außerdem sollten Sie sich der Tatsache bewusst sein, dass, nur weil Sie ein Modul referenzieren, die lose mit ihm verknüpften Java-Packages noch lange nicht für Ihren Code verfügbar sein müssen, Sie müssen sie nach wie vor zu Ihren Klassenpfaden hinzufügen – und zwar sowohl zum Klassenpfad der Hostmodus- als auch der Webmodustools (sowie – bei Verwendung von Eclipse – zur .launch-Konfiguration). Versäumen Sie dies, dann wird Ihr Java-Compiler (oder Ihre IDE) Ihnen mitteilen, dass der erforderliche Code nicht zu eruieren ist – was ein frustrierender Fehler sein kann, wenn Ihnen gerade entfallen ist, dass GWT-Module und Java-Packages nicht dasselbe sind!

9.1.1 Modularisierung in GWT

Wird die Modularisierung in der Praxis eingesetzt? Schon. Die GWT-Distribution selbst besteht aus einer Anzahl von Modulen: DOM, TextBox, History, JUnit, i18n, JSON usw. Abbildung 9.1 zeigt diese Module hierarchisch angeordnet.

Wenn Sie sich beispielsweise die Modul-XML-Datei für die Internationalisierung ansehen, werden Sie feststellen, dass diese die Standardeigenschaft locale definiert, den Java- Script-Code zur Bestimmung des verwendeten Webbrowsers angibt und zudem eine spezielle Java-Klasse namens Generator benennt, die für alle Internationalisierungsschnittstellen in Ihrer Anwendung ausgeführt werden sollte, um Java-Klassen zu generieren, die die Schnittstelle an die verschiedenen Eigenschaftsdateien binden. Module können durchaus leistungsfähig sein.

In diesem Abschnitt widmen wir uns zwei Dingen: Zunächst untersuchen wir alle Elemente, die im XML-Modul eines Moduls enthalten sein können, dieses XML-Modul sieht möglicherweise aus wie die in Listing 9.1 gezeigte, sehr umfassende Version. Dieses „erschöpfende" Listing enthält alle Aspekte. Im Laufe des Abschnitts werden wir Ersteres ebenso erschöpfend behandeln.

 

© 2009-2024 ciando GmbH