Remensvo

RAP (Rich Ajax Platform) erfreut sich als teil des EclipseRT-Projekts immer größerer Beliebtheit in Punkto Single Sourcing. Singel Sourcing beschreibt dabei die Idee, existierende RCP-Anwendungen als Webanwendungen zu deployen. Die Vorteile liegen hierbei auf der Hand: Wiederverwendung von Quellcode sowie des Wissens und der Erfahrung der Entwickler. Doch mit e4 am Horizont ergeben sich neue Ziele und Möglichkeiten für ein solches Szenario.

In Eclipse 4.0 wurde komplett aufgeräumt bei der Architektur von Eclipse. Unter anderem wurde mehr Wert auf die Mehrbenutzerfähigkeit gelegt, was uach bedeutet, dass RAP die Workbench nicht merh adaptieren muss, sonder “as is” wiederverwenden kann. Zwar fehlen momentan ncoh einige Features in RAP, die für die Applikationsentwicklung mit e4 nachzurüsten sind, doch werden diese zurzeit entwickelt und in das 1.3 Release (Helios) von RAP Einzug halten.

Theme- und CSS-Unterstützung

Wie vielen vielleicht schon bekannt sein dürfte (diejenigen die sich über e4 informieren), unterstützt e4 mit der CSS-Styling-Engine neue Möglichkeiten, die eigene Anwendung nach Belieben grafisch auzupeppen. Auch RAP bietet seit einigen Releases die Möglichkeit, das Theme durch den Einsatz von CSS nach den eigenen Vorstellungen anzupassen. Doch wie verhalten sich diese beiden Ansätze zueinander? Die Frage ist durchaus berechtigt. Der von der e4 verfolgte Ansatz beschränkt sich beim Theming auf das API von SWT. Es werden also nur von SWT bereitgestellte Möglichkeiten ausgeschöpft, die wiederum den Einschränkungen der Betriebssysteme unterliegen. Da RAP im Gegensatz zu SWT alle Widgets unter Kontrolle hat, können diese durch das Theming viel detaillierter angepasst werden. Durch den Fakt, dass die e4 CSS Engine auf SWT aufsetzt und das RAP Theming schon in der SWT-Implementierung von RAP vorhanden ist, kann beides ohne Probleme zusammenarbeiten.

Deklarative Oberflächen

Auch im Bereich der deklarativen Oberflächen hat sich im Kontext von e4 einiges getan. Zwei Projekte haben sich zum Ziel gesetzt, eine Lösung anzubieten, um Oberflächen deklarativ anstatt programmatisch zu definieren. Zum einen XWT, eine XML-basierte Beschreibungssprache für SWT (Standard Widget Toolkit) und JFace-Komponenten und zum anderen TM, das auf EMF-Modellen aufbaut (siehe Artikel –> kommt noch ). Da beide nur auf dem üblichen SWT aufbauen, ist es kein Problem, auch diese Technologien unter RAP wiederzuverwenden.

Kompatibilität mit Eclipse 3.x

Natürlich muss Eclipse 4.0 eine Rückwärtskompatibilität gewährleisten, um Anwendungsentwicklern Migrationsmöglichkeiten anzubieten. Das geschieht bei e4 als Teil der Kompatibilätsschicht, die sich darum kümmert, die alten APIs und Konzepte größtenteils auf die neuen Paradigmen umzulegen. Damit können Plugins, die für Eclipse 3.x entwickelt wurden, auch unter e4 genutzt werden – Gleiches gilt auch für RAP-basierte Anwendungen.

Die Zukunft von e4 und RAP

Auch in Zukunft werden die Teams von e4 und RAP eng zusammenarbeiten (hoffentlich ), um sowohl e4 als auch RAP als nächste Generation der Applikationsplattformen zu etablieren. RAP wird mit dem Helios-Release viele Features anbieten, die im Kontext von e4 notwendig sind. e4 selbst wird noch mehr auf die Wahl der Mittel achten, um die Plug-ins in verteilten Umgebungen besser nutzen zu können.

www.elipse.org/rap