Classic Components
One of the biggest challenges in migrating from Vaadin 7 or 8 to Vaadin Flow is that Flow is based on a different set of web components. The web components of Flow differ from their Vaadin 7 counterparts both in their API and behavior.
Classic Components is an add-on in Flow that provides a set of backwards-compatible components that ease migrating from Vaadin 7 or 8 to the latest Vaadin version. The API, behavior, and even the DOM structure of the components is made to mimic the Vaadin 7/8 components as much as possible.
Classic Components includes the following: HorizontalLayout, VerticalLayout, Panel, Label, GridLayout, and FormLayout.
These components either lack counterparts in Flow entirely, or have significantly different APIs, requiring a lot of modifications when migrating.
Classic Components also contain many abstract components from Vaadin 8 on which these components were based including AbstractComponent
, AbstractOrderedLayout
, and others.
To use Classic Components, only the imports for the supported components need to be changed to be able to use most of the same component features.
License
Classic Components is licensed under Commercial Vaadin Developer License 4.0 (CVDLv4) and part of the Prime Subscription. You’re asked to validate your license or start a trial period when you start using it.
Using Classic Components
Classic Components is intended for migrating your project from Vaadin 7 or 8 to the latest Vaadin version. The pack should work with any Vaadin version after 14, but it’s tested against Vaadin 23. The recommendation is to migrate to Vaadin 23.
To use Classic Components, you first need to add the dependency to your project’s pom.xml
or build.gradle
, as follows:
-
With Maven, add the pack dependency to
pom.xml
:<dependencies> <!-| other dependencies --> <dependency> <groupId>com.vaadin</groupId> <artifactId>vaadin-classic-components-flow</artifactId> </dependency> </dependencies>
After the dependency has been downloaded, you can start using the components by updating the component imports in your Java sources. For the components that are included in the pack, change the import statements to the corresponding Classic packages, for example,
com.vaadin.ui.VerticalLayout
tocom.vaadin.classic.v8.ui.VerticalLayout
.
Limitations On Use with Multiplatform Runtime (MPR)
Using Classic Components in combination with Multiplatform Runtime (MPR) isn’t recommended for this version since it can lead to styling conflicts between the two.
Configuring the Component Defaults for Vaadin 7
If you are upgrading from Vaadin 7, you can configure the Classic components to use the Vaadin 7 defaults with the system property vaadin.classic-components.vaadin7defaults
. By introducing the property (no value needed), the Vaadin 7 defaults are used.
Included Components
Full API documentation is at https://vaadin.com/api/com.vaadin/vaadin-classic-components-flow/
HorizontalLayout and VerticalLayout
Classic Components comes with HorizontalLayout and VerticalLayout designed to work and behave as close as possible to the corresponding components present in the Vaadin 7 or 8 versions. A few of the key features the components support include:
-
Expand Ratio: children with "expand ratio" defined share the available space among them based on their ratios
-
Alignment: each child can be aligned within its container (for example, top-left, middle-center, bottom-right, etc.)
-
Margin: each side of the component’s margin can be enabled or disabled independently
The DOM structure of VerticalLayout and HorizontalLayout was developed to maintain the same set of elements and CSS classes (such as v-verticallayout
/v-horizontallayout
, v-has-width
, v-expand
and so on), so that a project being migrated from Vaadin 7 or 8 is likely to be able to use its current styles without changes.
Class names defined in the layouts are added in the same way as before.
For example, if custom-style
is added to a VerticalLayout
instance, both custom-style
and v-verticallayout-custom-style
are added to the DOM element.
AbsoluteLayout
The Classic AbsoluteLayout resembles the Vaadin 8 version of AbsoluteLayout. It mimics HTML absolute positioning, letting you set an absolute position to its children.
Note
|
Missing features
ContextClickEvent and LayoutClickListener aren’t yet implemented in the Classic layouts.
|
HorizontalLayout and VerticalLayout are both Flow components, which means that they can be used together with any other component (Flow or other Classic Components).
Deviations
Unlike in the previous implementation, the layouts use flexbox, since this provides a nicer, cleaner way to achieve the same behavior, especially for the "expand ratio" and alignment features. If any of the styles in the project being migrated rely on the previous implementation, they might not work as expected with the Classic layouts.
VerticalLayout and HorizontalLayout use Lumo variables to define their spacing and margin sizes.
Valo Sass variable | Lumo CSS variable |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
FormLayout
The Classic FormLayout resembles, as much as possible, the Vaadin 7 or 8 version of FormLayout.
It shows all components added to it in a table with two columns.
The left column contains the component’s caption (except for Checkbox).
The components themselves appear stacked in the right column.
If a component is marked as required, an asterisk is appended to its caption.
As with HorizontalLayout and VerticalLayout, FlowLayout extends from the common superclass AbstractOrderedLayout
and a selection of methods in classes with the same names from the V8 inheritance hierarchy.
Note
|
FormLayout is also in Flow
FormLayout is also a Flow component, which means it can be used together with any other component (Flow or other Classic Components).
|
GridLayout
The Classic GridLayout resembles the Vaadin 8 version of this component. It supports row and column spans, row and column expand ratios, and cell alignment.
Panel
The Classic Panel component implements the same behavior as its counterpart in Vaadin 7/8 versions. It comes with updated styles based on the Lumo theme.
Deviations
While most of the API comes from the Classic API, there are a few methods that are either not implemented or have their signature changed.
For example, setIcon(Resource)
is deprecated, but you can use setIcon(Icon)
instead.
However, getIcon()
can’t be used, because it originally returns a Resource
instance.
Instead, the Classic Panel
introduces getIconAsIcon()
, which returns the Icon
instance set previously.
You can find the full list of unimplemented methods in "Incompatible and Unsupported API and Migration Instructions".
Label
The Classic Label component supports the same API as its counterpart in Vaadin 7/8.
The only unsupported API is setIcon()
.
As in Vaadin 7/8, it’s possible to change how the component interprets its contents.
The content mode can be ContentMode.HTML
, ContentMode.PREFORMATTED
, and ContentMode.TEXT
.
The default is ContentMode.TEXT
.
The caption can be interpreted as HTML by setting the mode with setCaptionAsHtml()
.
Deviations
Unlike in the Label component in Vaadin 7/8, the wrapper element is always present, regardless of whether a caption is set or not.
While this doesn’t affect the visual layout, it might break some CSS selectors.
For example, it might break use of a CSS direct-child selector, such as .my-class > .v-label
.
Another deviation from Vaadin 7/8 is when the content mode is set to ContentMode.HTML
.
Although the anchor and the image tags are still going to work, contrary to Vaadin 7/8, the script tags are completely removed from the content.
The same applies when the caption is interpreted as HTML.
Also, as previously mentioned, there is no support for setIcon()
at the moment.
Incompatible and Unsupported API and Migration Instructions
Any API that was already deprecated in Vaadin 8 (or 7) doesn’t exist in the Classic Components. You should thus change any code that uses the deprecated APIs before starting the migration.
Any Classic Component API that can’t work or is obsolete in Vaadin Flow is included in the Classic Components as @Deprecated
and doesn’t do anything except log a warning in development mode.
This is done to make it’s faster to get the project to compile and run, and enables you to see the migration results sooner without having to comment out code.
This section goes through both the incompatible and the unsupported API introduced by each Classic Component class and how you could mitigate the situation if using that API in your project.
The Component Interface
The base Component
interface from Vaadin 7 and 8 is replaced by the abstract class com.vaadin.flow.component.Component
in Flow.
Most of the API is still the same or has changed only slightly.
Classic Components introduces any missing API in the AbstractComponent
class instead.
Method signature | Mitigation |
---|---|
| Return type changed to |
| Return type changed to |
| Return type changed to |
| Migrate. Supported only by the classic |
| Remove/Migrate. Not supported by Classic Components, and no direct replacement in Flow. Alternatives are available in the Directory. |
| Remove/Migrate.
Not supported by Classic Components.
For Flow components, it depends on whether the component supports icons; for example, |
| Remove. You shouldn’t be even calling these methods as they are for Vaadin Designer integration only. |
The AbstractClientConnector Class
The Classic Components version of the class is in the com.vaadin.classic.v8.server
package.
Method signatures | Mitigation |
---|---|
| Migrate.
Flow components' |
| Remove/Migrate. Flow components can’t be extended with extensions. The method of migration depends on what the extension does. For pure server-side extensions, you can subclass the component. For extensions with client-side parts, you need to make a JavaScript file and call it from Java code inside the extended class. |
| Migrate.
For external usage, use distinct addXyzListener API in the component or |
| Remove. This method was only for internal usage; you shouldn’t be using it. It doesn’t apply for Flow. |
| Remove/Migrate.
|
| Remove. Internal method that doesn’t apply to Flow. |
| Migrate.
Doesn’t apply directly to Flow; you can get child components with |
| Remove/Migrate.
Doesn’t apply to Flow.
Manually set IDs can be used with |
| Migrate.
Flow doesn’t have a component-level error handler.
Migrate to use |
| Remove/Migrate.
No replacement available in Flow.
Use the |
| Remove. Not applicable in Flow. |
| Remove. Internal method that isn’t applicable in Flow. |
| Remove/Migrate. Not applicable in Flow. See documentation for Remote Procedure Calls (RPC) between the client and the server. |
| Remove. Internal method that shouldn’t even be used. |
| Migrate.
The event type is different; Classic Components have both |
The AbstractComponent Class
The Classic Components version of the class is in the com.vaadin.classic.v8.ui
package.
Method signature | Mitigation |
---|---|
| Remove/Migrate. Not supported by Classic Components and no direct replacement in Flow. The method of migration depends on what the error event was for. |
| Migrate.
You need to first check whether the component implements |
| Migrate. Not supported by Classic Components. See how to add shortcuts in Flow. |
| Remove/Migrate. Not supported by Classic Components and, in Flow, error messages are component-specific. |
| Remove. You shouldn’t even be calling this, as it was for Vaadin Designer integration only. |
| Migrate.
Supported only by the classic |
| Remove/Migrate. Not supported by Classic Components. In Flow, only field components can be read-only. |
| Remove/Migrate. Not supported by Classic Components. In Flow, only field components can have a required indicator. |
| Remove. Not supported by Classic Components or Flow components. |
| Remove/Migrate. Not supported by Classic Components, and no direct replacement in Flow. Alternatives are available in the Directory. |
CEBCC4DD-DDDD-44C3-ABA1-5DE81DF4891C