Seite 3: Deklaratives Styling

Inhaltsverzeichnis

Deklaratives Styling

Wohl einer der wichtigsten Aspekte aktueller Anwendungen ist ein schickes Aussehen. Zwar ist die Grundidee von SWT, alle Widgets des Betriebssystems zu verwenden und damit ein natives Look & Feel zu erzwingen, jedoch werden die Stimmen für ein besseres Styling von Eclipse-Anwendungen immer lauter. Zugegeben, RCP hat sich äußerlich in den letzten Jahren nicht viel weiterentwickelt. Größere Anpassungen des Look & Feel waren teilweise technisch nur schwer zu erreichen, teilweise sogar unmöglich. Die e4-Entwickler haben deshalb eine Styling Engine entwickelt, die es ermöglicht, SWT Widgets mit CSS (Cascading Style Sheets) in unterschiedlichen Aspekten zu verschönern. CSS war durch seine hohe Akzeptanz im Webumfeld die erste Wahl. Mit der CSS Engine ist es ohne größere Umwege realisierbar, entweder bestimmte Gruppen oder einzelne Widgets nach eigenem Bedarf zu dekorieren. Das ermöglicht es, Entwicklern von RCP-Anwendungen mehr Kontrolle über die Darstellung der Widgets zu geben. Hier ein Beispiel:

Shell, Button, Label { 
    background-color: rgb(48,48,48); 
    color: rgb(240,240,240); 
    font: Verdana 11px; 
}

Button:checked {
     background-color: #FF0000;
}

Auch erweiterte CSS-Konzepte wie Selektoren und Gradienten lassen sich mit der neuen CSS Engine nutzen, um ansprechende Anwendungen zu gestalten.

Web to Desktop

Inzwischen verschmelzen die Welten von Desktop- und Webentwicklung immer mehr. In vielen Anwendungsfällen sind Programmierer mittlerweile darauf eingestellt, Funktionen online nutzen zu können. Beispiele wie Online-Banking oder Online-Shops sind nicht mehr wegzudenken. Ein Ziel für Eclipse 4 ist, sich den Anwendungsfällen nicht zu verschließen, sondern sie zum eigenen Vorteil zu nutzen.

Die Idee ist, Komponenten aus dem Web ohne größere Hürden in eigene Applikationen zu integrieren. Als Beispiel wurde ein kompletter Editor mit "handelsüblichen" Webtechniken (HTML, CSS, JavaScript) geschrieben, der eigenständig mit einem Servlet interagiert. Die Webanwendung in Eclipse als eingebauten Editor zu nutzen war eine der Beweggründe für einen solchen Versuch. Während der Editor, wie angesprochen, als reine Webapplikation lauffähig ist, sollte er nicht nur innerhalb einer RCP-Applikation laufen, sondern sich in seine Umgebung integrieren. Beispielsweise war es Ziel, sich in den regulären Lebenszyklus eines Eclipse-Editors einzufädeln – also speichern, wenn man in Eclipse speichert, einen "Dirty Marker" setzen, falls der Benutzer etwas verändert et cetera. Die Entwickler erreichten das, indem sie die Eclipse-API dem eingebetteten Editor als JavaScript-API zur Verfügung stellten. e4 soll die grundlegende API der Workbench auch für andere Sprachen bereitstellen. Nicht nur das Einbetten von anderen Komponenten wird erleichtert, auch die Sprachbarriere soll in Eclipse 4 weitaus geringer ausfallen.

Zudem ist das Einbetten von sogenannten OpenSocial Gadgets in e4 Teil der Plattform geworden. Sie sind wiederverwendbare Webkomponenten, die sich an die Spezifikation von Googles OpenSocial Gadgets API halten. Bekannt sind sie durch Portale wie iGoogle oder auch XING. Hiermit eröffnet sich durch eine einheitliche Schnittstelle die Wiederverwendung existierender Komponenten für sogenannte Mash-ups.

Bisher war der Eclipse-Entwickler darauf angewiesen, alle Plug-ins in Java zu schreiben und zu verbreiten. Um die Limitierung zu überwinden, enthält e4 eine Abstraktionsschicht über OSGi, die erlaubt, Bundles/Plug-ins in anderen Sprachen als Java zu schreiben. Die Aufgabe der Schicht ist, Bundles in anderen Sprachen zu laden, die Abhängigkeiten aufzulösen und für die Sprache eine Laufzeitumgebung bereitzustellen.

Das Beispiel verwendet Rhino, um OSGi Bundles mit JavaScript zu schreiben. Durch die Abstraktion mit Context, Dependency Injection und Event Bus können nun Java- und JavaScript-Bundles miteinander interagieren, ohne zu wissen, in welcher Sprache die Gegenstelle geschrieben ist.

Desktop to Web

Eine andere Richtung, die die Eclipse Rich Ajax Platform (RAP) bisher eingeschlagen hatte, ist, durch "Single Sourcing" bestehende RCP-Applikationen als Webanwendung zur Verfügung zu stellen. RAP erreicht das, indem es SWT durch eine Alternativimplementierung ersetzt, die via HTTP mit einem Webbrowser kommuniziert. Vergleichbar mit der Umsetzung, dass SWT auf diversen Betriebssystemen die nativen Widgets benutzt, verwendet RAP die Architektur, um die Anwendung als JavaScript-Benutzeroberfäche im Browser zu verwenden. Als Anwendungsentwickler merkt man davon wenig, da sich RAP hinter den bekannten SWT-APIs versteckt und Implementierungsdetails somit hinter dieser Fassade versteckt.

Single Sourcing bedeutet, den gleichen Anwendungscode nicht nur für den Desktop-Bereich, sondern auch für die Webapplikation nutzen zu können. Mit RAP lässt sich aus einer Codebasis sowohl einen Desktop- als auch einen Webclient entwickeln. Single Sourcing bewahrt den Entwickler vor dem sonst unvermeidlichen Auseinandergehen redundanter Implementierungen der gleichen Logik. Zudem ermöglicht der Ansatz Java- und Eclipse-Entwicklern, ihr Wissen wiederzuverwenden, indem er ein Java-Programmiermodell unterstützt.

Tatsächlich kommen für Webclients mit RAP die gleichen Werkzeuge und APIs zum Einsatz wie für Rich-Client-Applikationen auf Eclipse-Basis. Das ist sinnvoll, da Ajax eine Desktop-ähnliche Bedienung anstelle des klassischen seitenorientierten Bedienkonzepts erlaubt. Wie sich ein Entwickler von Rich-Client-Anwendungen nicht mit den internen Eigenheiten einer Betriebssystemplattform befassen muss, kommt der RAP-Entwickler nicht mit Webtechniken wie Cookies, JavaScript und dergleichen in Kontakt. RAP ist seit geraumer Zeit eines der Projekte, die die Eclipse Foundation weiterentwickelt und hostet.

RAP ist allerdings nicht direkt Teil der e4-Entwicklung, die Projektmitglieder sind jedoch früh involviert in die Ideen und Entscheidungen, die für e4 getroffen werden. Da viele der für das nächste Eclipse entwickelten Konzepte wie XWT, TM oder der CSS-Support direkt auf SWT basieren, lassen sie sich ohne Weiteres in RAP nutzen. Somit ergeben sich Synergieeffekte, und es ist möglich, e4-Anwendungen ohne Anpassung als Webapplikationen nutzen zu können.