@Override
protected void configureNavigator(ViewDisplay applicationLayout) {
setNavigator(new MyNavigator(this, applicationLayout));
}
New & Noteworthy
1.1.2
Annotation Processor for linkki
The annotation processor previously developed separately from linkki has become part of linkki core. The Maven artifactId
has been changed to linkki-apt
to mark this inclusion. The documentation can now be found at linkki-apt. If you have been using the old annotation processor before its 1.0-RC01-Release, please also consider the changes documented in the corresponding New&Noteworthy.
New Annotations for Layouts
In addition to @UISection
, linkki now provides @UIHorizontalLayout
, @UIVerticalLayout
and @UIFormLayout
. These annotations can be used for PMO classes in the same way as @UISection
. In those layouts, labels are presented in the Vaadin default way. In a HorizontalLayout
, for example, labels for fields are displayed above the field and not beside the field. For more information on the Vaadin layout components, consult the Vaadin docucmentation on VerticalLayout and HorizontalLayout as well as FormLayout.
@BindStyleNames
for Sections
The aspect annotation @BindStyleNames
can now also be annotated on classes to use it for sections.
New Apsect: @BindCaption
Section and field captions can now be bound via @BindCaption
. In preparation for this, the AbstractSection
was refactored to allow setting (and removing) a caption after construction.
Selection of Table Rows
Table PMO classes can now implement the SelectableTable
interface to receive callbacks when the user selects a table row. Updating the current selection programmatically is also possible. Example can be found in the section Row Selection in Tables.
Defaults for Labels and Captions
Previously, a value had to be set for all @UI~
annotations' label/caption attributes. Now, the default value is "derived.by.linkki"
, which prompts linkki to use the capitalized property name as a label/caption. This is especially useful for rapid prototyping scenarios.
When using linkki with Faktor-IPS, the IpsPropertyDispatcherFactory
can now be used. It creates a IpsPropertyDispatcher
for Faktor-IPS model objects and uses the labels defined in the Faktor-IPS model for labels/captions marked with "derived.by.linkki"
. Note that this feature is not yet supported for component labels in row PMOs that are used as table columns.
The documentation has been expanded with a new section about the Faktor-IPS extension module.
LinkkiConverterRegistry
for UILabel
The LabelValueAspectDefinition
now uses the LinkkiConverterRegistry
to find converters for non-String values before defaulting to Objects#toString
.
Localized Captions with ItemCaptionProvider
DefaultCaptionProvider
now supports localization by calling getName(Locale)
to determine the caption, falling back to getName()
or toString()
(in order) if the method is not present. Additionally, IdAndNameCaptionProvider
has been moved to the Faktor-IPS-specific linkki module (now org.linkki.ips.ui.element.IdAndNameCaptionProvider
in org.linkki-framework:linkki-ips-vaadin8
), due to there being no general use-case if linkki is not used with Faktor-IPS. A deprecated version is still available, but will be removed in a future version.
Inherited aspects
Aspect annotation types can now be annotated with @InheritedAspect
to indicate that the aspect should also apply to subclasses (for classes) or implementing classes (for interfaces). Only one aspect of each annotation type can apply to a class, additional aspects are ignored. If the same aspect annotation appears in the super class as well as in an interface, only the annotation coming from the super calls will be respected.
This feature can be used when creating your own aspect, but also serves as documentation on aspects provided by linkki.
Custom PropertyDispatcherFactory
in DefaultBindingManager
The DefaultBindingManager
provides a new constructor that allows to set a custom PropertyDispatcherFactory
. If set, the DefaultBindingManager
uses this custom PropertyDispatcherFacotry
for all BindingContexts
that are created by using 'getContext()'. Read the section about PropertyDispatcher to get more information.
VaadinUiCreator in linkki-core-vaadin8
Obtaining a Vaadin Component
from UiCreator#createComponent
requires an additional cast and method call. The new VaadinUiCreator
directly returns a
Component
, but works the same otherwise.
New Navigator Configuration Concept
View changes in Vaadin are handled by the navigators. Previously, the linkki application framework provided an ApplicationNavigator
which extends the Vaadin Navigator
with convenient methods such as showView(String)
. The navigator of a LinkkiUI
is then configured by the ApplicationConfig
to use an ApplicationLayout
to display the views.
However, the concept of ApplicationNavigator
turns out to be inconvenient when using linkki with CDI or Spring, as both injection frameworks provide their own Navigators
that automatically discover views. In those cases, the linkki user is in the dilemma that the navigator must extend both ApplicationNavigator
and SpringNavigator
/CdiNavigator
.
To solve this problem, ApplicationNavigator
is now deprecated as well as the method ApplicationConfig#createApplicationNavigator
. Instead, a new method configureNavigator(ViewDisplay)
is provided in LinkkiUI
to configure the Navigator
. To make the API of LinkkiUI
more consistent, the existing method createErrorHandler
is also deprecated in favor of the new method configureErrorHandler
.
Navigating using Navigator
Until now | New |
---|---|
|
|
|
|
Configuring Navigator
To configure the navigator to use ApplicationLayout
, override LinkkiUi#configureNavigator(ViewDisplay)
, e.g.
@Inject
private CDINavigator cdiNavigator;
@Override
protected void configureNavigator(ViewDisplay applicationLayout) {
cdiNavigator.init(this, applicationLayout);
setNavigator(cdiNavigator);
}
private final SpringNavigator springNavigator;
@Autowired
public MyUI(SpringNavigator springNavigator) {
super(new MyApplicationConfig());
this.springNavigator = springNavigator;
}
@Override
protected void configureNavigator(ViewDisplay applicationLayout) {
springNavigator.init(this, applicationLayout);
// no need to set the navigator as that is done by Vaadin-Spring
}
API Changes in LinkkiUi
Until now | New | Notes |
---|---|---|
|
|
Old method is directly removed as it is no longer guaranteed that the configured navigator is an |
|
deprecated |
The error handler should be created and set in |
Setter Calls in Model Object
Previously, linkki was also using the setter of the property in the model object even if the PMO property had no setter. This is no longer considered valid, as omitting the setter is a conscious decision of the PMO creator. If you want to use the setter (and getter) from the model object, use a void
method in the PMO for Binding to the Domain Model.
Cases where the old behavior was implicitly used can be detected with the linkki-apt compiler option SETTER_ONLY_IN_MODEL_OBJECT
.
Allow ApplicationLayout#showView
for Views that are not Components
Previously, ApplicationLayout#showView
threw an IllegalArgumentException
if the given View
was not itself a Component
. Now, a View
overwriting View#getViewComponent()
can also be used. A View
that is neither a Component
nor overwrites getViewComponent()
will lead to an IllegalStateException
.
Fix notification of UiUpdateObservers
In cases where a UiUpdateObserver
modified the list of bindings, for example by adding a binding, the validation messages were not propagated to the new bindings because the observers were notified after validation messages were propagated. Now all UiUpdateObservers
are correctly notified first, after which the validation messages are propagated to all BindingContexts
.
Update Vaadin to 8.9.2
linkki now uses Vaadin version 8.9.2 to include the latest bug fixes and patches.