I wrote an article couple of weeks ago about automatic form generation, a topic that I think suits particulary well for Vaadin Flow. Although topic is kind of less relevant these days as your LLM tooling can generate code reasonably fast, iterating with the UI while your domain model is still in flux is not necessarily that fun (and all that generated code still needs to be maintained…).
Last week I dogfooded the AutoForm utility (available in Viritin add-on) on top of a Jakarta Data playground. Couple of enhancements I made then related to this “RAD” topic:
The layout of the generated form is now easier to override and defaults to FormLayout
There is now support for embedded records (like 1-to-1 relations, e.g. private Address address field in a Person pojo). Creates an “embedded form”
Related to two above points: “editors” and be configured to span on full row. E.e.g Address fields are grouped and start a new row.
ElementCollectionField now extends CustomField (supports regular field features → you get e.g. a label for table based subform of List<Address>).
If you want to try it now is a good time. I’m so enthusiastic about the topic that you’ll probably get features and bufixes quite fast Although I’m already considering a rewrite utilizing Annotation Processing (inspired by the implementation of Jakarta Data).
Can you “eject” the code for the form when you’ve outgrown the customization options that it provides? I always feel that this is pretty useful, otherwise you start from scratch when you reach that point.
That have crossed my mind as well, but as the current solution works by runtime inspection there would be some addition logic to implement that. With annotation processing based approach, one would get that for free (just copy to autogenerated form/grid from the target folder to your src folder)
That is one of my concerns with LLMs; Instead of writing 1 line of code and have your framework expand that to whatever is needed, we end up with X lines of lower-level code specifically tailored to whatever framework you’re using now.
We generate most of our UI. That has meant that migrating from an internal frontend to vaadin 7 to Vaadin 20+ has been reasonably painless. Most code that the developers write has not changed at all.
I do worry about the desire to use something ready-made do generate your UI. You are then stuck with whatever it can generate for you, and you can probably not take advantage of any internal conventions you might have.
In our case, we start with generating metadata classes from our database.
This reads in tables, columns, column type, foreign keys and any comments we’ve defined on the columns.
This metadata is then used to just list the columns we want.
From that you get the query and the field on screen.
If the column is a foreign key you get a popup/dropdown.
If the column name ends with _KG you might get automatic converter to LBS etc
Best of all. This is done exactly the same way for both a form and a list.
Although I’m already considering a rewrite utilizing Annotation Processing (inspired by the implementation of Jakarta Data).