Allow decorators for widgets

[vaadin-bot]

Originally by @magi42

---

Adding features to existing components can be difficult, especially because Java doesn't support multiple inheritance. Some sort of decorator interface would be useful. It should allow adding functionality without inheriting existing client-side components.

Some problem cases:

Problem 1: Multiple Features for Same ComponentThe same component can have multiple feature add-ons that currently use inheritance. For example, there are the following feature add-ons for TextField:

• AutoReplaceField
• SearchField
• CSValidatedTextField
• Stepper
• PasswordField
• AutoCompleteTextField
• ExpandingTextArea
• SwappablePasswordField
• SuperImmediateTextField

Combining two or more of these is a very relevant use case, but is not possible.

Problem 2: Multiple Components for Same FeatureSome features could easily be applied to several component types. Many current common component features could be implemented this way:

• Input prompt (TextField, ComboBox/Select, PopupDateField, ...)
• Tooltips, etc.

The feature would be described with an interface. For example, TextField, etc. would implement "Promptable" interface, which would be called by the attached decorator.

Problem 3: One-to-Many Mapping in Some ComponentsCurrently, the server-side TextField component is mapped to three different client-side implementations; VTextField, VPasswordField, VTextArea. A customization needs to inherit each of these widgets on the client-side, and because regular component-to-widget mapping is 1-to-1, each of them needs to have a separate server-side component as well. For example, CSValidation add-on needs to have CSValitedTextField, CSValidatedTextArea, and CSValidatedPasswordField.

SolutionAllow decorators that provide features without inheritance. For example, on the server-side:

TextField tf = new TextField("Email");
tf.addDecorator(new MakeLowerCase());
tf.addDecorator(new EmailValidator());
tf.addDecorator(new AutoComplete(addressbook));
tf.addDecorator(new InputPrompt("Give it to me"));

Decorators would have a server-side implementation, which is mapped 1-to-1 to a client-side implementation.

On the client-side, the decorators would need:

• Hook after construction
• Hook for updateFromUIDL()
• Ability to add event listeners

Client-side widgets could provide built-in support for specific features (such as input prompt).

The server-side might also need some hooks, possibly in constructors, paintContent(), and chageVariables().

Question: Is there need for purely server-side decorators?

ProblemsType checking is a major issue that would need to be solved in the server-side API; how to check either runtime or (preferably) on compile time which decorators can be added to which components. Having addDecorator() in AbstractComponent would imply run-time type checking. The issue is probably similar to addListener().

[stale[bot]]

Hello there!

It looks like this issue hasn't progressed lately. There are so many issues that we just can't deal them all within a reasonable timeframe.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!

[stale[bot]]

The issue was automatically closed due to inactivity. If you found some new details to it or started working on it, comment on the issue so that maintainers can re-open it.