linkki might be the perfect fit for you if you have the following requirements:
You have UI pages that have to reflect a large domain model with complex business logic.
You don’t want to spend too much time and effort in the development of the UI. This is often the case if the application tries to fully automate processing, leaving the UI only for those use cases that require manual interaction by back-office staff.
You prefer to code both domain logic and UI in Java.
You can use linkki with plain Java, with Spring Boot, Spring inside an application server or JEE.
linkki is available from Maven Central and can be included via Maven/Gradle:
linkki is a framework to build the UI layer for a business application. The only assumption about the business layer is that you use a domain (entity) model to capture the structure of the business data.
linkki is a server side framework that can support different UI frameworks. Therefore, it is divided into a UI framework independent core and UI framework specific modules like
linkki-core-vaadin-flow. linkki's core module is UI framework independent, but it needs a UI framework specific implementation to work. We offer such implementations based on Vaadin, which allows you to write UI in Java. The layouts and widgetsets are provided by Vaadin. It also handles the whole communication between the browser and the server.
However, the code has only very few direct dependencies to Vaadin API when using linkki. Most of the interaction with Vaadin is encapsulated by linkki.
The fundamental building blocks for a linkki UI are sections. A section is defined as a group of related (input) fields/controls. For example, a section might contain the data about a person such as name and date of birth. The fields for the address such as country, city and street might be grouped together in another section. linkki provides standard layouts for the sections to give the UI a consistent look and to speed up your development. The following screenshot shows the two mentioned example sections.
Presentation model objects (aka view model) as explained by Martin Fowler are used to provide data for the UI and to process data changed in the UI. To put it simple, you can write one PMO for each section when using linkki. Section PMOs are annotated with annotations that define how a section looks. At runtime, linkki creates the (Vaadin) layouts and controls based on the annotations.
The following is the PMO code for the partner data section shown above.
To move the data from the UI controls through your PMOs to the domain model and back, linkki provides a data binding mechanism.
Each time the user changes the data in a field, linkki calls the
appropriate setter method in the PMO. For example if the user changes
the person’s name,
setName(newName) is called. In the same way,
provides the name displayed in the control. The following diagram
illustrates the interaction between User Interface and Business Layer.
In the sample code above, the PMO reads and updates the domain model. As
you can see, the code is already repetitive with only two fields. To reduce
the overhead in code, linkki allows you to bind the controls directly to
properties in the domain model if you don’t need to apply any transformation
or calculation to the displayed data. The following is a shorter
PartnerSectionPmo which uses the above explained linkki feature.
Instead of the getter and setter method you just need to write a placeholder method and declare the attribute/property name in the annotation. Additionally, you have to provide an annotated method that returns the model object. linkki then binds the controls directly to the domain model. The mechanism also supports more than one model object per section.
linkki is not only able to bind field values to PMO properties but can also bind other typical aspects such as enabled state, visible state and the available values shown in a combo box. In fact, all properties of a UI control can be bound this way.
To demonstrate this, we extend our previous example: A partner might now be either a person or a company. The date of birth field should then only be enabled for persons. Here is the new section and the code for enabling the date of birth field depending on the type of person.
In the date of birth annotation, the
enabled attribute specifies that the
enabled state of the control should change dynamically. linkki uses a naming
convention to find the method that calculates the dynamic state. In this case,
the calculation is done in the method
UI code written using linkki has a very clear structure. Each section is defined by one PMO. If you name your PMO classes after the section headlines, you can find the relating code of any given section in seconds even if you are unfamiliar with the code base.
There is a lot more that helps you to build a whole business application such as:
Simple API to create tables with dynamic content
Automatic highlighting of inputs based on validation logic defined in the business layer
Support of PMO based creation of sections in dialogs
An overall application layout with an application menu
Bug reports, new ideas and improvements can be created in the GitHub issue tracker
Collaboration on issues/tasks via pull requests
Copyright Faktor Zehn GmbH.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.