I’ve been thinking of writing an article about the benefits of pure-Java UI toolkits, and as my primary example I’d write a Vaadin application that introspects an object and creates forms automatically for calling each method. In my example, an EJB is injected into the application and has a method such as MyBean#create(MyPojo p) that persists MyPojo in the back end. A form would be created for MyPojo that lists all the fields. If any field is another POJO, then a nested form would be created. If any field is a Set or List, then the form could be extended using tree controls to fill out more information.
Assuming I get the time to do this, I was going to extend BeanItem (I think) to handle all of the above. Before I begin, can someone who knows forms/bean items/field factories/etc let me know if BeanItem seems like the correct place to start with this?
The point of this work is to show how useful Java-based UIs are, as I think it would be more difficult to do the same thing with JSF/Struts etc. But this utility class would be a big part of it and I might as well take a shot at writing it. Then, if it works and no one complains, you’re welcome to it.
If I were to build a system such as your suggestion – provided that I understood your description – I’d probably stay within the FieldFactory. The field factory can return instances of Form for nested forms and the Set/List tree controls can be done by implementing custom fields using Henri’s
CustomField component .
I’d probably leave BeanItem etc in their original implementations.
Indeed, CustomField is probably the way to go to implement this. However, in its current form, it is not very easy to use and is severely lacking examples for different use cases.
I’ll try to get back to improving it someday. In the meanwhile, feel free to suggest improvements or provide patches if you modify it.