Component and UI Extensions

Also a UI can be extended in a similar fashion. In fact, some Vaadin features such as the JavaScript execution are UI extensions.

Implementing an extension requires defining a server-side extension class and a client-side connector. An extension can have a shared state with the connector and use RPC, just like a component could.

The server-side API for an extension consists of class that extends (in the Java sense) the AbstractExtension class. It typically has an extend() method, a constructor, or a static helper method that takes the extended component or UI as a parameter and passes it to super.extend().

The extension could then be added to a component as follows:

Adding a feature in such a “reverse” way is a bit unusual in the Vaadin API, but allows type safety for extensions, as the method can limit the target type to which the extension can be applied, and whether it is a regular component or a UI.

Extension Connectors

An extension does not have a corresponding widget on the client-side, but only an extension connector that extends the AbstractExtensionConnector class. The server-side extension class is specified with a @Connect annotation, just like in component connectors.

In the following example, we implement a “Caps Lock warning” extension. It listens for changes in Caps Lock state and displays a floating warning element over the extended component if the Caps Lock is on.

The extend() method gets the connector of the extended component as the parameter, in the above example a PasswordFieldConnector. It can access the widget with the getWidget().

An extension connector needs to be included in a widget set. The class must therefore be defined under the client package of a widget set, just like with component connectors.