Vaadin 8.3: Verbesserungen an den Integrationsbibliotheken für CDI & Spring

Einfacheres Styling einiger Komponenten

In Vaadin 8.3 unterstützen DateField-Komponenten das Festlegen von benutzerdefinierten Stilnamen für einzelne Daten, während RadioButtonGroup und CheckBoxGroup für ausgewählte Elemente einen Stilnamen ausgewählt haben. Die Komponente Grid verfügt nun über eine Methode, mit der gesteuert werden kann, ob das Grid-Element die Events von Komponenten in seinen Spalten verarbeiten soll, die von dortigen Komponenten propagiert werden. So kann zum Beispiel die Auswahl oder das Ziehen und Ablegen in einer Spalte erfolgen, die Komponenten enthält. Die MenuBar unterstützt verschiedene Inhaltsmodi für QuickInfos in den MenuItems, sodass beispielsweise HTML-Formatierungen verwendet werden können. Mit der aktuellen Version von Vaadin ermöglicht es einem die Methode Binder.setReadOnly direkt, die Bearbeitung aller gebundenen Felder zu verhindern.

Weitere Verbesserungen in CDI- und Spring-Integrationsbibliotheken

Das Interessantere an dieser Veröffentlichung findet man allerdings in den Add-ons „Vaadin CDI 3.0“ und „Vaadin Spring 3.0“, die zusammen mit Version 8.3 des Frameworks veröffentlicht wurden. Beide Integrationsbibliotheken unterstützen nun die HTML-5-History-fähige Navigator-Implementierung, die für das Framework bereits in der Version 8.1 freigegeben wurde. Das bedeutet, dass die meisten Vaadin-Anwendungen sich von den Deep-Linking-URLs des Old-School-Hashbang-Stils verabschieden können. Diese Funktion kann und sollte in den meisten Fällen derzeit noch aktiviert werden, wenn die alten URLs noch unterstützt werden müssen. In dem GitHub-Repository von Matti Tahvonen kann man sich ein Beispiel ansehen, wie man dieses Verhalten implementieren kann.

Zuerst muss der Navigator in der Applikation initialisiert werden. Dort wird der Verweis auf die benötigten Elemente definiert. In unserem Fall sind es die beiden Views, die in den Klassen MainView und SecondView implementiert sind.

    @Override
    protected void init(VaadinRequest vaadinRequest) {
        setNavigator(new Navigator(this, this));
        getNavigator().addView("second", SecondView.class);
        getNavigator().setErrorView(MainView.class);
        // Most Vaadin apps are inited so that the fragment is already available
        // here and that is enough
        checkForLegacyHashBangUrl();
        // If you might have links in your Vaadin app to hash bangs, like we 
        // have for demo purposes here in the MainView, also do the check in
        getPage().addUriFragmentChangedListener(e-> checkForLegacyHashBangUrl());
    }

Die Klasse SecondView ist recht überschaubar.

public class SecondView extends VerticalLayout implements View {

        private Label label = new Label("");

        public SecondView() {
            label.setCaption("Second View");
            addComponent(label);
            addComponent(new Button("Go to MainView", e->getUI().getNavigator().navigateTo("")));
        }

        @Override
        public void enter(ViewChangeListener.ViewChangeEvent event) {
            label.setValue("Parameters: " + event.getParameters());
        }
    }

Hier wird mit dem Drücken von dem Button mittels Navigator auf die erste Seite verwiesen.

getUI().getNavigator().navigateTo("")

Wer mehr über den Navigator lesen möchte, dem empfehle ich folgende Dokumentation: Vaadin – Docu – Navigator.

In der Klasse MainView allerdings sehen wir zwei Varianten, wie auf die SecondView verwiesen werden kann.

public class MainView extends VerticalLayout implements View {
  private Label label = new Label("");
  public MainView() {
    label.setCaption("Main View");
    addComponent(label);
  }
  @Override
  public void enter(ViewChangeListener.ViewChangeEvent event) {
    label.setValue("Parameters: " + event.getParameters());
    addComponent(new Button("Go to SecondView",      
                 e->getUI().getNavigator().navigateTo("second")));
    addComponent(new Link("Go to SecondView with legacy link", 
                 new ExternalResource("/#!second/with/some/parameters")));
  }
}

Die erste verwendet wieder den Navigator:

getUI().getNavigator().navigateTo("second")

Die zweite Methode erzeugt einen Link nach alter Manier:

new ExternalResource("/#!second/with/some/parameters")

Wie aber wird der Link nun verarbeitet? Hier kommt die Methode checkForLegacyHashBangUrl aus dem Beispiel zum Einsatz. Das URI-Fragment wird angesehen (uriFragment.startsWith("!")) und dann entscheidet man, welchen Weg man gehen möchte.

    protected void checkForLegacyHashBangUrl() {
        String uriFragment = getPage().getUriFragment();
        if(uriFragment != null) {
            if(uriFragment.startsWith("!")) {
                // Assume this is a legacy hashbang URL, assign directly to Navigator and clear
                getNavigator().navigateTo(uriFragment.substring(1));
                getPage().setUriFragment(null);
            } else {
                // Some other fragment, just ignore or do what you have done before
            }
        }
    }

Das Add-on „Vaadin CDI 3.0“ enthält auch wichtige Umbauten und Verbesserungen. Der Navigator unterstützt jetzt eine ähnliche Autokonfiguration, die bereits früher in der Spring-Integration eingeführt wurde, einen neuen Scope mit dem Namen VaadinSessionScope, eine bessere Cluster-Unterstützung und ein verbessertes View-Context-Lifecycle-Management.

Besonderer Dank für diese Verbesserungen geht an das aktive Community-Mitglied Tamás Kimmel. Beziehen kann man Vaadin über die Release-Webseite – Happy Coding!

Bei Fragen oder Anregungen können unsere Leser Sven Ruppert über Twitter per Handle @SvenRuppert oder via Mail (sven.ruppert@gmail.com) erreichen.