Die Migration verlief eigentlich mit geringen Aufwand. Theoretisch hätte man nur die plugin.xml anpassen müssen. Die bestehenden Views des Plug-Ins erweitern nun nicht mehr den Extension-Point: org.eclipse.ui.views sondern org.eclipse.rap.ui.workbench.views. Ebenfalls ändern sich die Dependencys des Plug-Ins hin zu org.eclipse.rap.*.

Da das RAP Projekt mir aktuell als Milestone 3 vorliegt, funktioniert halt noch nicht alles. So musste ich die Verwendung des ProgressMonitorDialog ausbauen. Dieser Dialog erschien immer dann, wenn beim Blättern im Baum Daten aus der Datenbank nachgeladen werden mussten. Ohne diesen verhält es sich in RAP nun so, dass der Zweig aufklappt und ein Ordner Symbol erscheint. Die Maus bekommt eine Sanduhr neben den Zeiger bis die Daten geladen sind. Danach wird der Ordner mit den richtigen Knoten nebst Symbolen ersetzt. Ich finde diese Darstellung charmanter als den Dialog, besonders bei Ladezyklen von wenigen Sekunden.

Etwas gemeiner ist die Restriktion, das man bei einen TableViewer oder TreeViewer aktuell den Input nur einmal setzen kann (Bug). Dies lässt sich aber mit dem Workaround von Jochen Krause umgehen.

Nach diesen Änderungen hatte ich die Anwendung im Intranet verfügbar. Ein paar Macken sind noch zu beheben.

Das ich als Entwickler eine UI programmiere die sowohl als RCP wie auch im WEB funktioniert ohne das ich unterschiedliche Programmierparadigmen benutzen muss, ist super. Wenn RAP released wird, steht zu erwarten, dass ich nicht mal mehr den Java Code ändern muss. Ein Austauschen der plugin.xml sollte dann reichen.

Natürlich wird diese Vision nicht ganz erreichbar sein, da RCP immer noch Vorteile gegenüber AJAX hat, wie die Möglichkeit zu zeichnen. Ebenso sind RCP Anwendungen nicht zwangsläufig Mulituserfähig. Das Projekt bringt einen aber nahe an diese Vision heran.

Diese vorgestellten Datenbankrefactorings unterscheiden sich nun aber von denen, die man im mittlerweile im Alltag durchUnterstützung der IDE am Quellcode von Java oder anderen OO Sprachen vornimmt. Dies ändert sich bei OO Code sofort, wenn man Klassen ändern möchte die von dritten verwendet wird.

Daher finde ich, das man bei Refactorings stärker unterscheiden sollte, ob man interne Strukturen der Software die in einem Team liegen, ändert oder kommunizierte API anpassen möchte. Denn bei API Änderungen kommen auch in der Objektorientierung andere Refactoring Techniken zum Einsatz. So werden beispielsweise Schnittstellen um neue Methoden erweitert, indem bei einem Interface ein neues Interface mit der neuen Methode angelegt wird, was das bestehende Interface erweitert. Wenn die Schnittstelle über eine abstrakte Klasse definiert ist, so kann dort die neue Methode recht einfach als leere Methode implementiert werden. Alte Methoden hingegen werden als deprecated gekennzeichnet und nicht sofort gelöscht.

Damit sind die Unterschiede zwischen den vorgestellten Refactorings an DB Schemata und OO Sourcen nicht mehr so groß. Solange man das DB Schemata nur mit einer Anwendung verwendet, kann man es noch als keine publizierte API ansehen und mit leichtgewichtigen Prozessen Refactorings durchführen.

Für DB Refactorings gibt es aber bislang noch wenig Tool Unterstützung, dort sollte StIXDB künftig besser unterstützen können.