Aysada Blog

Bei der Arbeit habe ich vor einiger Zeit ein kleines Plug-In geschrieben, dass hierarchische Datenstrukturen darstellt und in einem zweiten View Details zu den selektieren Datensatz anzeigt. Nun sollte dieses Plug-In einen größeren Kreis an Nutzern zur Verfügung gestellt werden. Da die neuen Nutzer nur das Feature des Plug-Ins benötigen und keine weiteren Features der bestehenden RCP-Anwendung habe ich das Plug-In als RAP Anwendung umgebaut. Damit wird die Verteilung auch etwas leichter.

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.

Ich habe am Dienstag einen Vortrag über Datenbank Refactoring gehört. Dieser Vortrag basierte auf dem Buch von Scott W. Ambler und Pramod J. Sadalage. Bei dem Vortrag ging es vor allem um das Refactoring von Datenbank Schemata, die von mehreren Anwendungen verwendet werden. Dies erfordert einen entsprechenden Prozess der die Änderungen kommuniziert und den Entwicklern der verschiedenen Anwendungen die Zeit gibt, sich auf das neue Schemata einzustellen.

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.

Wir haben angefangen für Mylar einen Repository Connector zu Synergy Change zu bauen.