Saturday, November 25, 2017

A first look at Vaadin Flow / Vaadin 10

Only recently the guys from Vaadin published the developer preview of thier upcoming Vaadin 10 release. As I have been teaching Vaadin 8 I wanted to catch up and see what Vaadin 10 will bring.

There is a big change in that Vaadin turns away from using GWT for its client side Components. It has a whole new direction in that client side Components are now implemented using Polymer and WebComponents. Let's say it as it is - this could be a game changer.

So I went for the starter apps provided on the Vaadin Website and tried the Hello World Examples. There are no archteypes yet, at least there is a TODO there. The first thing one notices is, that we get quite a bunch of dependencies, Vaadin has been split up into mutliple modules, and we see a lot of webjars for the components.

This is where my confusion started: I have all the components as webjars, but they are listed once again in a package.json to be resolved by bower. The documentation on this is confusing, you can go with bower only, you need it at least for the moment for the production build, and it says that in the future there may be a way with webjars only. That I have every component twice really gave me a puzzler.

Then I tried to take a dive into the existing documentation, and for now I can say that I understood that there are many ways of using Vaadin 10.


  • One can work as we used to to using Vaadin Components. The way navigation is handled has changed fundamentally, but the principles of using Vaadin in a way like we are used from Desktop UI Frameworks, with Java Components organized in a Tree can be done as before.
  • There is a new low-level Elements API that lets us manipulate the Dom on the server side. Unfortunately this is the first chapter in the docs. Maybe this is the last thing I want to do.
  • It is really very easy to integrate any existing Polymer Component to be used as a server side component. Indeed this is so easy that using the built in Vaadin Components is completely optional.
  • Probably the most exciting stuff to me is the PolymerTemplate class. One can create a HTML Template with Polymer (I managed to to this without digging any deeper into polymer). Vaadin Flow Provides a mechanism to synchronize a so called TemplateModel between Server and Client. The Model is basically described as an interface or pojo on the server side, Flow sync it to the client and the values can be bound on the client side into the Polymer template. Not to forget that Events on the client can be easily bound the methods on the server by simply adding an annotation.

To sum it up:

  • The state of the developer release might be a little confusing. Especially the webjars/bower dependencies. But there are signs that this may change until the final release. The docs are in an early state put they are already quite helpful.
  • If we want to, we can work with Vaadin Components as we did before - The biggest change may be the new routing mechanism.
  • We get a plethora of webcomponents that we can use with Vaadin easily. At Devoxx Belgium one of tha Vaadin guys told me that there will be even a generator to create the server-side Java classes,
  • Using templates and polymer, it's no big deal anymore to move stuff to the client side if desired.
  • I'd really like to see the Binding API work alongside with the TemplateModel

One thing that I wished for, but found no solution: Writing the client side in Kotlin/JS. Hopefully some genius will create a Kotlin/Polymer Binding. Up to now you have to use ES6 Javascript Syntax.

Saturday, May 6, 2017

Using Mapstruct with Protobuf3

Mapstruct works pretty nice for mapping protobuf3 Builders. The List get a suffix of "...List" in the Builder. As they are immutable and the adder method does not match that name I created a NamingStrategy to fix that:

Monday, March 6, 2017

Multitenancy with Hibernate, Postgres, Vaadin 8 & Kotlin

This example application uses Postgres Table Inheritance to setup a Multi-Tenant Database with separate schemas for each tenant.
It is built using Kotlin, Hibernate, Spring Boot, and Vaadin8 for the UI and includes several Selenium Tests that could be used as a starter for testing Vaadin applications.
Hibernate switches tenants with a proxied EntityManagerFactory/Datasource and has an additional TenantFilter Column to allow cross-tenant selects from the master schema.
The example app allows you to register for an account, login and has a simple user management.
There are examples for mapping Pojos to Postgres JSON Columns for Hibernate and JOOQ inside.
There is a docker postgres image included.
Run it with docker run -p5433:5432 eiswind/postgresql:9.6 to execute the Integration Tests or just to try the app.

Sunday, January 29, 2017

Migrating to Vaadin 8 (beta, continued)

Today I finished my migration of a (small) demo app to the new Vaadin 8 API.

First of all: Vaadin 8 has a compatibility layer. Everything you may have used with Vaadin  7 will still work with Vaadin 8, you just have to change some package names in your import statements. (for e.g. ui gets ui.v7) and everything will work out of the box with Vaadin 8.

But my goal was to completely remove the compatibility layer. That needed quite a bit of work, as the new DataBinding API focuses on binding bean properties. My app used the PropertySetItem in a bunch of places. To move these I created backing beans and used the new API.

binder.forField(passwordMatchField)
        .withValidator(PasswordMatchValidatorV8(passwordField))
        .bind(LostPasswordBean::passwordMatch)

This was not too hard, but there was more work to be done as I had to migrate all of my custom Validator implementations. The new Validator signature tastes better than the v7 one, but changing them introduces even more work:

class PasswordMatchValidatorV8 constructor(private val src: PasswordField) : 
    Validator<String> {

    override fun apply(value: String, ctx: ValueContext): ValidationResult {
        val pw: String = src.value        
        if (pw != value) {
            return ValidationResult.error(NO_MATCH)
        }
        return ValidationResult.ok()
    }

    companion object {
        const val NO_MATCH = "Passwords don't match"    }
}

That did make up for most of the fields. Another place where I had to change the code was the old BeanItemContainer  that I used to bind Collections to Grids etc. Here we have new API too that looks like this:

grid = Grid()
grid.addColumn{ u -> u.email }.setCaption("Username")

dataProvider = ListDataProvider(users)
grid.dataProvider = dataProvider
That's it. Took me about a day for 9 View Classes, but remember I was very slow getting used to the new binding style.

For my personal taste the new binding api is a great step forward, and it makes heavy use of SAM types. Using it with Kotlin is a breeze. It's is still far away from beeing as powerful as the good old eclipse databinding api, which is still my personal favorite when it comes to ui databindings.


Sunday, January 15, 2017

Kotlin Properties and the Vaadin 8 BeanBinder

Vaadin 8 (currently in beta) comes with a whole new DataBinding API that makes heavy use of the Java 8 Lambda Features.

Unfortunately Java has no concept of a Property, so one of the new ways to bind a Bean Property is writing something like (Taken from the documentation):

binder.bind(nameField, Person::getName, Person::setName);

Since Kotlin has a concept for a property you may want to write something like:

binder.forField(nameField)
        .bind(Person::name)


Thats possible with an extension method for the Vaadin Binder that could probably look like this:

fun <BEAN, T> Binder.BindingBuilder<BEAN, T>.bind(prop: KMutableProperty<T>) {
    this.bind(
            ValueProvider { bean: BEAN -> prop.getter.call(bean) },
            Setter { bean: BEAN, v: T -> prop.setter.call(bean, v) })
}

Have fun with Kotlin & Vaadin!