Andreas Lange from Pivotal recently published an insightful example where a Vaadin application dynamically generates a grid and a form based on domain objects annotated with metadata that provides hints for the presentation layer. This inspired me to revisit a topic that is both old and new in the Vaadin ecosystem.
The binder vs. dynamic form generation
In typical Vaadin applications today, the UI takes center stage, with Java view classes explicitly defining form layouts, including which fields are present. Developers rely on Vaadin's Binder to streamline the synchronization of data between domain objects and UI fields, reducing boilerplate code. Some enthusiasts, like myself, even build custom binders to further optimize the process.
However, an alternative approach exists: dynamically generating forms based on the data model (i.e., domain objects) with minimal manual UI definition. This method actually used to be the only official approach in Vaadin until version 7. The framework's now abandoned Form component automatically generated forms. Developers simply provided customization hints, and the framework handled the rest.
Pros and cons of dynamic form generation
Advantages
- Enables rapid creation of large-scale UIs with minimal effort.
- Reduces the amount of UI code, leading to cleaner and more maintainable applications.
- Particularly useful when the backend data model is still evolving and subject to frequent changes.
Challenges
- Customization and fine-tuning the UX can be more difficult compared to a manually crafted UI.
- May not offer the same level of flexibility as a traditional,
Binder-based approach. - It can be difficult not to mix the domain model with the UI layer, for example leaking UI related annotations to domain objects.
Over time, manually defining forms and binding data programmatically became the de facto standard in Vaadin development. While I was still heavily involved in Vaadin R&D, we noticed that dynamically generated forms were rarely used in real-world projects. Instead, developers preferred defining form UIs explicitly and binding them to DTOs. This led to the development of helpers like PrecreatedFieldsHelper, which later influenced the Binder API.
Despite the decline of Vaadin's built-in dynamic form generation, the approach still holds value in specific scenarios, such as:
- Rapid Application Development (RAD)
- Administrative UIs
- Prototyping and initial project iterations
Current options for dynamic forms in Vaadin Flow
Vaadin currently provides some Hilla-based components for dynamic form generation, but there is no out-of-the-box solution for Java developers using Vaadin Flow—despite Flow being particularly well-suited for this kind of rapid UI development. Fortunately, Java's powerful Reflection API has enabled many Vaadin developers to build their own custom tooling for reducing UI code overhead in large applications.
Here are three starting points for implementing dynamically generated forms in Vaadin Flow:
1. Develop your own tooling
As demonstrated in Andreas' example, developing a tailored form generation mechanism is not overly complex. A simple prototype can be built using a few classes and Java's raw Reflection API. The advantage of this approach is complete control over customization and adaptability to specific project requirements.
If I were to implement this myself, I would avoid direct usage of low-level reflection APIs and instead leverage higher-level libraries for introspection. Some useful options include:
- Apache Commons BeanUtils – Provides a more convenient way to inspect and manipulate JavaBeans.
- Jackson library – Often available in Java applications. Although Jackson is not designed for this use case, its internal parts can be (mis)used for these purposes.
A more advanced variation of this approach could extend beyond form/grid generation. For example, the EntityExplorer project I published last autumn automatically generates Vaadin CRUD UIs for all JPA entities found in the persistence context—without requiring a single line of application-specific code. Simply adding the dependency delivers a functional admin UI instantly. The UX sure isn’t perfect, and some data types might not be supported; zero development cost can make this a tempting approach for some limited use cases.
2. The Crud UI Add-on
The Crud UI Add-on has long, from the Vaadin 7 era, been the go-to tool for generating CRUD forms (and grids) based on domain objects. It is not to be mistaken with the commercial CRUD component, which does not generate forms automatically. With the Crud UI Add-on, developers define adapters for CRUD operations—such as FindAllCrudOperationListener, AddOperationListener, UpdateOperationListener, and DeleteOperationListener—and specify property orders or custom fields where necessary. The result is a fully functional CRUD view with just a few lines of code.
However, the downside of the Crud UI Add-on is its relatively plain UI. While it provides a quick way to generate forms, customizing the UX can be limited. Additionally, the add-on's development has slowed in recent years, and it, for example, lacks support for modern Java date types.
3. AutoForm tooling in Viritin
The EntityExplorer utility I previously mentioned is built on top of an experimental feature in the Viritin add-on called AutoForm. Compared to the Crud UI Add-on, AutoForm is a bit more lower-level approach that focuses solely on form generation without handling data listing (which has become much easier with recent Vaadin Grid API improvements 🎉).
AutoForm supports a wide range of data types, including:
- Modern Java date types
- Enums
- Element collections
Additionally, AutoForm respects the property order defined in Java sources, reducing the need for manual configuration. You’ll essentially just create the form and attach save, delete and reset handlers for it.
For further customization—such as changing field types or handling relationships and custom data types—developers can programmatically modify field generation using AutoFormContext, which can be registered as an application-scoped bean. You can customize, for example, all fields of a certain Java type or only in the context of a certain domain object.
Check out the full example application that shares the backend with the Crud UI add-on demo.
Conclusion
While Vaadin’s current approach favors manually defined forms with Binder, dynamically generated forms still hold significant value, particularly in the early stages of a project or for applications that require rapid prototyping and bulk UI generation.
Depending on your needs, you can:
- Build your own custom form generation mechanism with Reflection and higher-level Java libraries.
- Use the Crud UI Add-on for quick CRUD views.
- Leverage AutoForm in Viritin for flexible automated form generation.
Each of these methods provides a different balance of automation and flexibility, allowing developers to choose the best approach for their specific use case.
If you have experience with dynamically generated forms in Vaadin (I know many have!), I’d love to hear your thoughts and approaches in the comments below or the Vaadin community forum!