Plus: Simpler component styling

Vaadin 8.3: Improved integration libraries for CDI & Spring

Matti Tahvonen
Vaadin
© Shutterstock.com / 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.

@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());
}

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(label);
            addComponent(new Button("Go to MainView", e->getUI().getNavigator().navigateTo("")));
        }
 
        @Override
        public void enter(ViewChangeListener.ViewChangeEvent event) {
            label.setValue("Parameters: " + event.getParameters());
        }
    }

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

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

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");
    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")));
  }
}

The first one makes use of the navigator again:

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

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
            getNavigator().navigateTo(uriFragment.substring(1));
            getPage().setUriFragment(null);
        } 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 (sven.ruppert@gmail.com).

Author
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.

Comments
comments powered by Disqus