Plus: Simpler component styling

Vaadin 8.3: Improved integration libraries for CDI & Spring

Matti Tahvonen
© / Jellis Vaes

Vaadin 8.3 is now officially available; meaning that the first version with the new “Release Train Mode” has been released. In this article, Matti Tahvonen presents some insights into implemented bugfixes and the many nice features which have been included in this milestone.

Simpler styling of components

In Vaadin 8.3, DateField components support the assignment of custom style names for individual data, while RadioButtonGroup and CheckBoxGroup have specified a style name for selected items. The Grid component now provides a method for controlling whether it should process the events of components in its columns, which are propagated by their respective components. For example, you may select or drag and drop in a column containing components. The MenuBar now supports different content modes for menu item tooltips, allowing you to i.a. use HTML formatting. Lastly, the current version of Vaadins Binder.setReadOnly method offers the possibility to prevent the processing of all bound fields.

Further improvements to CDI and Spring integration libraries

However, the more interesting aspects of our release can be found within our Add-ons “Vaadin CDI 3.0” and “Vaadin Spring 3.0”, which were released alongside version 8.3 of the framework. Both integration libraries now support the HTML-5-history-enabled Navigator implementation, which has already been released for our framework in version 8.1. This means that most Vaadin applications can kiss those deep-linking URLs of the old-school hashbang style goodbye. If the old URLs are still to be supported, there is a function for that which should probably, for now, be used in most cases. There is an example of how to implement this behavior in Matti Tahvonen‘s GitHub repository.

Firstly, the Navigator needs to be initialized. A reference to the necessary elements is defined in the application. For us, it is the two views implemented in the classes MainView and SecondView.

protected void init(VaadinRequest vaadinRequest) {
    setNavigator(new Navigator(this, this));
    getNavigator().addView("second", SecondView.class);
    // Most Vaadin apps are inited so that the fragment is already available
    // here and that is enough
    // 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());

The class SecondView is fairly straightforward.

public class SecondView extends VerticalLayout implements View {
        private Label label = new Label("");
        public SecondView() {
            label.setCaption("Second View");
            addComponent(new Button("Go to MainView", e->getUI().getNavigator().navigateTo("")));
        public void enter(ViewChangeListener.ViewChangeEvent event) {
            label.setValue("Parameters: " + event.getParameters());

Clicking on the button refers us via Navigator to the first page.


To learn more about the Navigator, I recommend: Vaadin – Docu – Navigator.

In the class MainView, however, there are two variants how to refer to the SecondView.

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

The first one makes use of the navigator again:


The second method generates a link the old way:

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

But how will the link be processed? For this, the method checkForLegacyHashBangUrl of our example is used. After the URI fragment is viewed (uriFragment. startsWith ("!")), one decides which way to go.

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
        } else {
            // Some other fragment, just ignore or do what you have done before

The add-on “Vaadin CDI 3.0” also contains important modifications and improvements. The Navigator now supports a similar autoconfiguration which was originally introduced during Spring-Integration, a new scope called VaadinSessionScope, better cluster support and improved view context lifecycle management.

Special thanks for these improvements goes to the active community member Tamás Kimmel. Vaadin can be purchased via the release website – Happy Coding!

For questions or suggestions, you can contact Sven Ruppert via Twitter @SvenRuppert or via mail (

Matti Tahvonen
Matti Tahvonen has a long history in Vaadin R&D: developing the core framework from the dark ages of pure JS client side to the GWT era and creating number of official and unofficial Vaadin add-ons. His current responsibility is to keep you up to date with latest and greatest Vaadin related technologies.

Leave a Reply

3 Comments on "Vaadin 8.3: Improved integration libraries for CDI & Spring"

Notify of
Benjamin P Erridge

This is a much needed enhancement!


This article initially redirected me to some prize/sweepstakes page, with no way to get back to the article. Please figure out why this is happening Jaxenter – I really like your publication but this has happened to me multiple times now.

Gabriela Motroc

Thank you for the heads up! Our team is working on fixing the problem