UI components

The arrangement of the various components in a UI definition is controlled by layout components. These form containers where components like text fields or combo boxes are placed and laid out according to the container‘s layout type. Furthermore binding of component properties with data source properties is defined, which also features visibility, validation and conversion.

Desktop-like experience

Provide browser based applications with the look and feel of a native desktop application: comfortable, ergonomically arranged and handsome.


Add support for smartphones, tablets or mobile data scanner etc. in a single development environment, providing various mobile specific layouts, navigation trees, menus, tables and actions just like on any desktop environment.

Future-proof apps

Exploit the ubiquitous HTML5 platform to be future-ready for coming requirements being independent from specific mobile platforms.



The following UI components are available for use in any UI view: label, text area, text field , date field, decimal field, form, numeric field, reference field, search field, search panel, button, checkbox, combo box, image, list select, options group, panel, progress bar, splitter, table, tab-sheet.

Framework independent

Build an abstract structure for your user interface without any dependencies to a concrete implementation, whether for desktop or mobile use. This will be interpreted at runtime by various renderers, e.g. Vaadin UI, Vaadin Touchkit for mobile, SWT and others.

Property binding

Bind data sources needed to UI components and determine how data objects are mapped to the components. It even works for collections e.g. bind one to many relationships to a table component with a single line of definition. Bind components among themselves and let e.g. the selected item of a list appear in another text field without any code. While property value changes are propagated to other properties, validation and conversion can be defined.

Function library & services


Select the way how the components should be arranged, choosing from layout types such as vertical, horizontal, grid, or form layout. Decide how components are positioned inside layouts – according to the container layout type, responsive or absolute. Nest any layout type within another to create ergonomic user interfaces.


Simply define a data source and let the autowiring rule engine select suitable UI components and bind them using Property Binding. The rule engine will deduct the component placement from data source metadata. Visual component groups within a view automatically arise from nested DTO, derived (subclassed) entities or grouping of attributes of entities. E.g.: from an entity “Product” two other specializations: “Medicine” with an additional attribute “on prescription” and “Perishables” with the additional attribute “best before” will be placed in 2 different panels: one showing the “Product” data and if applicable, another showing the respective specialized attribute of the currently displayed product type.


The autolayout functionality will provide a suitable nested layout for UI views by using rules defined in a specialized DSL.

Layout strategy


As part of the application logic a visibility processor decides the degree of user interaction with components. This feature can help focusing the user`s attention, reduce big forms to essential or avoid unwanted changes. The visibility processor controls various attributes of UI components: read-only, disabled or visible. Rules to control an attribute can be defined and bound to a UI component.

Styling and format

Styles define a set of presentation attributes using a Cascaded Style Sheet (CSS). You can assign a variational style for each UI component or complete layouts containing components to enhance readability or attract attention. Some components such as decimal or text fields can contain further format information: e.g. define decimal precision and masked text input.


Preview the arrangement of UI components while modelling in the IDE view.

DSL Grammar