Rich Clients mit JavaFX am Beispiel von JOffice

RCP-Anwendungen mit FX RCP Light

Ramin Assisi
©Shutterstock.com/ra2studio

Mit der Einführung von JavaFX bestand erstmalig die Möglichkeit, Java ohne Verwendung weiterer Bibliotheken für die Cliententwicklung auf allen Plattformen einzusetzen. Oracles neues Flaggschiff kommt mit allerlei Hilfsmitteln daher, die bisher oft in anderer Form in RCP-Anwendungen realisiert worden sind, wie beispielsweise das Data-Binding-Konzept. Das Verschmelzen mit der Komponentenarchitektur als auch mit den bisherigen Konzepten der Eclipse RCP stößt hierbei auf einige Probleme, die das neue Projekt JOffice auf innovative Art lösen will. Das Ergebnis ist ein leichtgewichtiges Framework, das neben einer ansprechenden Benutzeroberfläche den Vorzug hat, mithilfe von EMF sowie eines eingebauten Tooleditors leicht anpassbar zu sein. Über den Aufbau des neuen Frameworks und seine Anwendung in JOffice.

Vor einigen Jahren entstand die Idee, ein kleines Office-Programm in Java zu schreiben. Hintergrund war der Bedarf vieler Firmen nach einer wenig problematischen Integrierung mit bestehenden Anwendungen und nach einer Abkopplung von den Updatezyklen der großen Office Suites. Ein weiterer Anstoß war die Freigabe des Microsoft-Office-Formats als ECMA-Standard „OOXML“. Aufgrund der reichhaltigen Erfahrungen in der Eclipse-Plattform fiel die Entscheidung für die Implementierung auf der Basis von SWT/Draw2D. Mit dem Auftauchen von JavaFX ergab sich jedoch eine völlig neue Situation. Statt sich mit den Akzeptanzproblemen einer SWT.DLL herumzuärgern, bestand jetzt die Aussicht, das Ganze noch einmal aus einem (Java-)Guss herzustellen.

Sofort stellte sich die Frage nach der Integrierbarkeit mit der Eclipse-Plattform. Dank der Initiative von bestsolution.at, dem exzellenten Projekt mit dem leider etwas sperrigen Namen e(fx)clipse, konnte das Problem der OSGi-Anbindung leicht gelöst werden. Dieses Framework bot sich naturgemäß auch als Erstes an. Doch Versuche ergaben, dass für eine Anwendung, die in Zukunft auch einmal (hoffentlich) auf einem Smartphone seine Dienste tun soll, der klassische RCP-Ansatz zu schwergewichtig ausfallen würde. Andererseits kommt EMF bereits leichtfüßig daher. Mit CDO und Co. sollte schließlich auch zukünftige Kollaboration nicht ausgeschlossen werden. Also stand sehr bald fest: Das UI wird wie beim Eclipse 4 auf der Basis eines EMF-Schemas gerendert. Bei näherer Betrachtung der bisherigen RCP-Konzepte fiel jedoch auf, dass eine moderne Benutzeroberfläche, die auch von Normalsterblichen bedient werden kann, in der Regel nicht so aussieht, wie es sich die Erfinder des Eclipse RCP vor über zehn Jahren vorgestellt hatten. Viele der gut durchdachten Konzepte wirken sich leider beim Durchschnittsanwender kontraproduktiv aus, insbesondere, weil sich ihr Sinn erst nach einer Weile und damit zu spät erschließt. Mittlerweile haben sich außerdem einige Konzepte für leicht zu bedienende Oberflächen etabliert, sodass es an der Zeit war, diese Konzepte zielgerichtet in einem Framework umzusetzen.

Das UI-Konzept

Abbildung 1 zeigt das Konzept anhand eines Beispiels aus JOffice.

Abb. 1: Grundsätzlicher Aufbau eines FX-RCP-Clients am Beispiel von JOffice

Auf der linken Seite befindet sich eine Toolbar. Die dort angeordneten Buttons öffnen jeweils ein im FX-Sprachgebrauch so genanntes „Akkordeon“. Um auf dem begrenzten Platz alles unterbringen zu können, können diese auch ineinander verschachtelt werden. Selbstverständlich sollte der Benutzer die Möglichkeit haben, die seitliche Toolbar je nach Geschmack auch auf der rechten Seite zu platzieren. Ein weiterer Klick auf einen Toolbar-Button führt bei geöffnetem Akkordeon schließlich wieder zum Zuklappen, sodass der Platz für den in der Mitte angeordneten Editor wieder frei wird.
Überhaupt müssen sich heutige Anwendungen, was den Bildschirm betrifft, auch mit wenig Platz begnügen können. Deshalb ist die Tabkomponente bis in die Titlebar des Fensters verschoben. Bei FX RCP Light handelt es sich deshalb um ein UNDECORATED Window. Das heißt, dass die Möglichkeit eines völlig freien Aufbaus innerhalb der gesamten Fensterfläche besteht. Der Startmenü-Button dürfte auch aus anderen Desktopanwendungen bekannt sein. Er führt den Benutzer immer an einen wohldefinierten Punkt, nämlich zur Homepage, während die Quick-Tools in der Titelleiste ständig präsent sein sollen. Der Homepagebereich (Abb. 2) stellt einen Stack (StackPane) dar, der eine Vielzahl von Homepages, die sich vom Objekt JOAbstractHomePage ableiten, enthalten kann.

Abb. 2: Der Homepagebereich

Dabei können auch spezielle Implementierungen genutzt werden. Hierzu zählen die Anzeige einer Internetseite sowie die Anzeige eines Office-Dokuments (z. B. eines Handbuchs). Eine Default-Implementation kann beispielsweise für eine Beispielseite oder eine About-Seite erweitert werden. Für alle, die auch mal die gesamte Fensterfläche für den Editor freigeben wollen, befindet sich in der rechten oberen Ecke ein Button, der es ermöglicht, alle Toolbars zuzuklappen. Rückgängig machen lässt sich dies durch Bewegen der Maus an den oberen Fensterrand. Je nach Kontext, also beispielsweise abhängig davon, um welchen Editor es sich handelt, befindet sich oben jedoch unterhalb der Tab-Komponente eine weitere Toolbar, die die so genannten Ribbon-Tools enthält. Das Konzept hierbei ist, dass die wichtigsten Werkzeuge für den jeweiligen Kontext zur Verfügung gestellt werden. Wer Vollständigkeit benötigt, ist eher mit der Sidebar gut bedient.Es versteht sich von selbst, dass sich mithilfe von CSS Styles die gesamte Oberfläche gestalten lässt. Die benötigten IDs ergeben sich aus den mitgelieferten Themen.

Die wichtigsten Konzepte im Überblick

Das Window
Das Window, in FX Stage genannt, ist als „undecorated Window“ ausgeführt. Somit steht die gesamte Fensterfläche für die Anzeige- und Steuerelemente zur Verfügung:
• Standard-Window-Buttons (Minimize, Maximize und Restore)
• Maximize in Window: Hierbei werden alle Toolbars sowie die Statusbar entfernt, sodass der gesamte Fensterbereich für die Anwendung (Editoren, Views etc.) zur Verfügung steht.
• Quick Toolbar: Die Werkzeugleiste kann für Aufgaben, die so gut wie immer benötigt werden, in die Titlebar eingeblendet werden.
• Der Startmenü-Button: Der Benutzer kann immer wieder an einen wohldefinierten Ort zurückkehren.
• Side Toolbar: Diese Toolbar sollte möglichst alle verfügbaren Werkzeuge für eine bestimmte Perspektive enthalten.
• Top Toolbar: Die hier angebotenen Werkzeuge stellen eine Untermenge derjenigen der Side Toolbar dar, deren Auswahl sich nach der Häufigkeit der Benutzung richtet.

Aufmacherbild: Businessman doing paperwork with futuristic digital background von Shutterstock / Urheberrecht: ra2studio

[ header = Seite 2: Das EMF-Modell als Grundlage ]

Das EMF-Modell als Grundlage

Die Herausforderung an ein Modell (Abb. 3) bestand darin, auf der einen Seite das angestrebte Design effizient zu unterstützen und auf der anderen Seite nicht allzu viel an Flexibilität in Bezug auf Erweiterbarkeit zu verlieren. Zentrales Domainobjekt ist das JOffice. Der Anwender erhält dabei eine Kopie eines Templates, das nach der ersten Anmeldung erstellt wird. Das RCP-Konzept der Perspektiven wurde inhaltlich übernommen und taucht als List-Attribut des JOffice-Objekts auf. Die im letzten Abschnitt beschriebenen Toolbars spiegeln sich in den Attributen sideToolbar und topToolBar wider, während Startmenü und Quick-Tools Elemente des JOffice-Objekts selbst sind.

Abb. 3: Ausschnitt aus dem RCP-FX-Light-Modell

So richtig zur Sache geht es schließlich mit den frei konfigurierbaren Tools. Diese können in Baumstrukturen angeordnet werden, wobei ToolGroups jeweils weitere ToolGroups bzw. Tools beherbergen können. Die visuelle Ausprägung kann dabei unterschiedlich ausfallen. Ist eine ToolGroup der TopBar zugeordnet, so stellt sie sich als RibbonToolBarGroup dar. Wird die gleiche ToolGroup jedoch der SideBar zugeordnet, so wird diese auf der obersten Stufe als Button auf eben dieser und auf Unterstufen als FX-Akkordeons gerendert. Die Gruppenhierarchie wird dabei in Form von verschachtelten Akkordeons implementiert. Doch davon mehr im nächsten Abschnitt.

Der JOffice Default Renderer

Im letzten Abschnitt wurde bereits die Umsetzung des Modells in die visuelle Darstellung besprochen. Dabei handelt es sich um die Standardimplementierung. Es besteht die Möglichkeit, diese zu überschreiben, um beispielsweise eine andere Darstellung auf einer mobilen Anwendung zu erhalten. Alles, was hier benötigt wird, ist die Implementierung einer eigenen Factory-Klasse, wobei das Interface IJOFactory implementiert werden muss. Für ausgefallenere Wünsche besteht darüber hinaus die Möglichkeit, die UIC.fxml-Datei sowie den dazugehörigen FX-Controller anzupassen.

Der Tooleditor

Zwar kann die Gestaltung der gesamten Bedieneroberfläche durch programmatische Änderungen am Modell bewerkstelligt werden. Gerade bei komplexeren Layouts ergab sich aber für JOffice die Notwendigkeit, einen Editor für diese Aufgaben zur Verfügung zu haben. Das Ergebnis ist ein eingebauter Editor (Abb. 4). Dieser kann mit der Tastenkombination SHIFT + ALT + X gestartet werden. Eingaben führen nach Klick auf „Apply“ zur sofortigen Änderung in den jeweiligen Toolbereichen. Grundsätzlich unterstützt dabei der Editor alle Controls, die auch in JavaFX verfügbar sind. Die Anbindung der Toolaktionen erfolgt über die ID. Der Editor stellt dabei sicher, dass diese immer nur eindeutig vergeben werden können. Ein Formatattribut ermöglicht ausreichende Flexibilität, sodass zukünftige Erweiterungen nicht auch immer eine Schemaänderung nach sich ziehen.

Abb. 4: Der Tooleditor

Commands und Services

Das JOffice-Framework verfügt über ein sehr einfaches und dennoch leistungsfähiges Command-Pattern. Hierbei wird vor jeder Aktion automatisch ein JOCommand-Objekt erzeugt. Dieses führt das Modellobjekt ETool mit sich. Die Commands werden in einem Stack verwaltet und stehen somit den Undo bzw. Redo Handlern zur Verfügung. Undo- und Redo-Buttons müssen allerdings im Rahmen des UIC bereits erzeugt sein. Alle Useraktionen führen schließlich dazu, dass diese Commands einem Serviceverteiler zur Ausführung übergeben werden. Dieser entscheidet, welcher Service die weitere Verarbeitung übernehmen soll. Dies geschieht anhand eines Enum-Objekts EserviceId. Ein spezielles Mapping sorgt für die Umsetzung der Toolpfade in die richtige Service-ID.
Redo und Undo sind funktional für Änderungen am EMF-Modell als auch für Modelländerungen an Office-Dokumenten bereits fest implementiert. Für andere Fälle müssen die entsprechenden Handler überschrieben werden.

[ header = Seite 3: Anwendungsentwicklung ]

Anwendungsentwicklung

Zwar wurde Das JOffice-FX-UI-Framework ursprünglich für das JOffice selbst entwickelt. Es eignet sich jedoch auch dafür, in Rekordzeit eine komponentenbasierte FX-Anwendung praktisch „zusammenzuklicken“. Das EMF-Modell kann dabei auch für die Modellierung der Anwendung selbst verwendet werden und durch das eingebaute CDO auch als klassisches Client-Server-System verteilt werden. Das Framework besitzt hierfür neben der bereits besprochenen Toolunterstützung auch ein Konzept für so genannte UseCase-Objekte. Diese stellen quasi Editoren dar, die auf Objekte im EMF-Modell zugreifen. Im Normalfall wird ein solcher UseCase in einem eigenen Plug-in untergebracht. Listing 1 zeigt ein Beispiel für solch eine Klasse.

public class EContactsUseCase extends AbstractUseCase implements IUseCase {
  public EContactsUseCase() {
    super(JOModel.USE_CASE_CONTACTS);
  }
  @Override
  protected EViewController createController() {
    return new EContactsUseCaseController();
  }
  public EContactsUseCaseController getController() {
    return (EContactsUseCaseController) super.getController();
  }
  @Override
  public String getDisplayName() {
    return "Contacts";
  }
}

Einige wenige Klassen genügen, um einen Editor zu erhalten. Der Controller ist ein FX-Controller im Zusammenspiel mit einer .fxml-Datei. Um die Verbindung mit dem EMF-Modell zu erleichtern, leitet sich diese zuständige Klasse von EViewController ab. In einem ModelManager muss lediglich noch das Root-Objekt konfiguriert werden:

if (editingDomain == null) {
  editingDomain = AdapterFactoryEditingDomain
    .getEditingDomainFor(JO.session.getJoffice().getContacts());
  Resource resource = JO.session.getResource();
        editingDomain.getResourceSet().getResources().add(resource);
...

Hat man mit dem FX Scene Builder dann die .fxml-Datei erstellt, muss man die FX Control Properties mit dem Modell verbinden:

firstNameProperty = bind(firstName, firstNameProperty, contact,
  JofficePackage.eINSTANCE.getEContact_FirstName(), editingDomain);e

Das Contacts-Beispiel aus der e(fx)clipse-Demo wurde angepasst und liegt dem Framework als ContactsUseCase bei (Abb. 5).

Abb. 5: Der Use Case „Contacts“

Remote-Steuerung mit CDO

Ein besonders interessanter Anwendungsfall ist die Verwendung des Frameworks für eine Client-Server-Lösung. Das JOffice-FX-RCP-Framework kann dabei in Bezug auf die Persistierung wahlweise mit einer einfachen lokalen Datei (.xmi) oder aber auf der Basis eines CDO-Servers betrieben werden. Durch den Parameter mode=remote wird beim Start der Clientanwendung im Falle einer Entwicklungsumgebung (Aufrufparameter dev=true) der CDO-Server vor der eigentlichen Clientanwendung gestartet und anschließend eine CDO-Session aufgebaut. Das JOSession-Objekt ist für den Aufbau einer Clientsession zuständig. Darüber hinaus kann von hier aus auch programmatisch die Einrichtung der Tools betrieben werden. Der im vorherigen Abschnitt beschriebene Editor erkennt automatisch, ob es sich um eine Remoteanwendung auf CDO-Basis handelt, und richtet einen EditingDomain-Listener ein, sodass echte Kollaboration ermöglicht wird.

Anzeige und Bearbeitung von OOXML (*.docx-, *xlsx- und *.pptx-Dateien)

Im Falle der Verwendung des hier dargestellten Frameworks erhält man die Option der nahtlosen Integration von Office-Funktionalitäten in die Anwendung. Um beispielsweise ein MS-Office-Dokument einzubinden, genügt folgender Aufruf:

IEditor editor = IJOFactory.factor.createEditor(File file, Tab tab);
TabPane node = editor.getMainPane();

Im Rahmen des Frameworks reicht sogar folgende Zeile:

IJOFactory.factor.createDocument(File file);

Der hier frei erhältliche Stand in Form eines Windows-Installers demonstriert bereits, dass selbst ein komplexes und umfangreiches Dokument wie die ECMA-Dokumentation des OOXML-Standards bereits in guter Qualität gerendert werden. Die Performance ist erstaunlicherweise sogar größer als diejenigen der großen Office-Suiten (Tabelle 1).

Open Office Libre Office MS Office JOffice
24 s 34 s 24 s 11 s

Tabelle 1: Benchmark: Laden des 181-seitigen ECMA-Word-Dokuments in Sekunden

Tests ergaben darüber hinaus, dass eine Reihe von Dokumenten bereits korrekter dargestellt wird als beispielsweise mit der neuesten Apache-Open-Office-Version. Allerdings wird es noch bis zum Jahresende dauern, bis eine erste Version für zunächst einfachere Anwendungen zur Verfügung stehen wird. Diese geplante erste Version der Office-Komponente verzichtet dabei zunächst auf selten benötigte Funktionen insbesondere bei der Bearbeitung. Besonders interessant ist die Verwendung für generierte Reports, da die Generierung von PDF entfällt. Erzeugte Dokumente können stattdessen als Office-Dokumente noch nach der Generierung vom Benutzer manuell angepasst werden.

FX RCP Light – kurz und bündig
Das FX-RCP-Light-Framework war ursprünglich fest mit JOffice verbunden. Mittlerweile sind die meisten Komponenten, die für die Entwicklung nötig sind, in separate Plug-ins ausgelagert worden. Für das 3. Quartal 2014 ist eine erste Version mit einer EPL-Lizenz geplant. Ein Projektantrag wurde bereits bei der Eclipse-Community gestellt. Die Office-Komponente ist für Anfang 2015 geplant. Über eine Open-Source-Lizenz hierfür wurde noch keine Entscheidung getroffen. Für alle Projekte, die sich für mobile Plattformen offen halten wollen, ist FX RCP Light eine mögliche Alternative. Auch für die rapide Prototypenentwicklung eignet es sich. Die zu erwartende Office-Integration könnte in einigen Fällen noch interessant werden. Das Framework wird auf allen Java-8-Plattformen lauffähig sein. Langfristig ist der Einsatz als Websoftware mit Java Web Start denkbar.

Fazit

Das FX-RCP-Light-Framework von JOffice bietet ab der neuen Java-8-Version schnelle Ergebnisse für die Erstellung von Rich Clients auf der Basis von JavaFX. Wer auf die Anwendungsentwicklung mit EMF setzt, erhält darüber hinaus einen Werkzeugkasten, um mit dem eingebauten CDO auch Client-Server-Systeme zu erstellen. Last but not least besteht laut Angaben des Herstellers auch ab Anfang des nächsten Jahres die Möglichkeit, das ebenfalls eingebaute Office in die Anwendungen zu integrieren. Aufgrund des geringen Ressourcenverbrauchs eignet sich eine solche Lösung auch für die Verteilung auf Citrix-Servern. Bis auf die Office-Laufzeitumgebung sind alle Komponenten als Eclipse-Plug-ins mit der Open-Source-Lizenz EPL geplant. Wer eine Vorabversion des Frameworks bereits ausprobieren möchte, kann dieses über die Homepage von JOffice kostenfrei anfordern.

Geschrieben von
Ramin Assisi
Ramin Assisi
Ramin Assisi hat an der TU Berlin Informatik studiert und ist selbstständiger Softwareentwickler und IT-Berater. Er ist maßgeblich an der Entwicklung von FX RCP Light sowie JOffice beteiligt. Zurzeit ist er bei der Volkswagen AG als IT-Architekt im Einsatz.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: