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

© Shutterstock.com / Jellis Vaes
Vaadin 8.3 ist nun offiziell verfügbar und ist damit das erste Release, das mit unserem neuen „Release Train Mode“ herausgekommen ist. In diesem Artikel geben wir einige Einblicke in die umgesetzten Bugfixes und die vielen netten Features, die es in diesen Milestone geschafft haben.
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 ([email protected]) erreichen.
Hinterlasse einen Kommentar