JavaFX-2.0-Integration mit Eclipse 4.x

JavaFX 2.0 und Eclipse

Im Eclipse SDK (Eclipse IDE) gibt es keinen vorinstallierten JavaFX-Support. Abhilfe schafft hier Tom Schindl (von BestSolution.at [5]), eine bekannte Größe im Eclipse-Universum. Tom hat mit e(fx)eclipse [6] eine hervorragende JavaFX-Integration für Eclipse geschaffen, mit der man sofort loslegen kann. Als IDEs für die JavaFX-Entwicklung werden zurzeit Eclipse 3.7.1 und 4.2 unterstützt. Neben der einfachen Einbindung von JavaFX in Java-Projekte werden auch OSGi und die Eclipse 4 Application Platform unterstützt. Dafür hat Tom unter anderem eine JavaFX-2.0-basierte Rendering Engine implementiert. Diese habe ich erweitert, um die Basisanforderungen der Contacts-Demo abzudecken. Das Ergebnis sehen Sie in Abbildung 4. Die e4 + JavaFX-basierte Contacts-Demo ist im Wesentlichen der gleiche Quellcode, wie die Original e4 + SWT-basierte Contacts-Demo. Einzig die Implementierungen der List und Details Views basieren jetzt direkt auf JavaFX 2.0. Der ganze Rest des Applikations-UIs ist im Eclipse 4.x Workbench Model modelliert und wird von der neuen JavaFX-2.0-basierten Rendering Engine gerendert. Die aktuellste Implementierung der Contacts-Demo mit allen dazugehörigen Runtime-Projekten finden Sie bei GitHub unter [7].

Abb. 4: e4-Contacts-Demo mit JavaFX Renderer in dunklem CSS Styling
Das Eclipse 4.x Workbench Model und UI-Toolkit-spezifische Renderer

Eine der großen Neuerungen im Vergleich zu Eclipse 3.x ist die Einführung eines auf EMF (Eclipse Modeling Framework) [8] basierenden Workbench-Modells. Das hat verschiedene Vorteile, unter anderen die klare Trennung zwischen dem generischen UI-Modell und der zum Rendern verwendeten UI-Technologie. Zum Beispiel gibt es ein Modellelement MMenu, das ein Menü repräsentiert. Analog dazu gibt es MMenuItem und MMenuSeparator. Im Fall des Standard-SWT-Renderers wird immer dann, wenn im Modell ein MMenu benutzt wird, auf Rendering-Seite ein SWT-Menü benutzt. Modelländerungen werden dann über Subscribtion-Mechanismen an den Renderer weitergegeben. Der Renderer hat wiederum dafür zu sorgen, dass Änderungen im realen UI in das Modell überführt werden. Listing 1 zeigt exemplarisch einen JavaFX-basierten Renderer für Menüs. In der Methode createWidget()bekommt man als Parameter das eigentliche Workbench-Modellelement und ein Parent-Modellelement übergeben, das allerdings auch null sein kann. In diesem Fall handelt es sich um die Hauptmenü-Bar der Applikation, die mit einem JavaFX MenuBar Control gerendert wird. In allen anderen Fällen soll das Modellelement als JavaFX Menu gerendert werden. In der Methode processContents()wird dafür gesorgt, dass alle JavaFX-Menüs die gleiche „Verdrahtung“ bekommen wie die entsprechenden Workbench-Modellobjekte.

Listing 1
public class MenuBarRenderer extends JFXRenderer {

  @Override
  public Object createWidget(MUIElement element, Object parent) {
    if (!(element instanceof MMenu)) {
      return null;
    }

    if (parent != null) {
      String label = ((MUILabel) element).getLocalizedLabel();
      label = label.replaceAll("&", "_"); // JavaFX Mnemonics
      Menu menu = new Menu(label);
      menu.setMnemonicParsing(true);
      return menu;
    }

      // Kein parent, also Haupt-Menü
  MenuBar menuBar = new MenuBar();
    return menuBar;
  }

  @Override
  public void processContents(MElementContainer container) {
    super.processContents(container);

    if (container.getWidget() instanceof MenuBar) {
      MenuBar menuBar = (MenuBar) container.getWidget();
      for (MUIElement e : container.getChildren()) {
        menuBar.getMenus().add((Menu) e.getWidget());
      }
    } else if (container.getWidget() instanceof Menu) {
      Menu menu = (Menu) container.getWidget();
      for (MUIElement e : container.getChildren()) {
        menu.getItems().add((MenuItem) e.getWidget());
      }
    }
  }
}
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.