Vaadin 7 Complex Form(s) best practices?

Hi! I’m reaching out to the Vaadin 7 gurus as to the best, all around, approach of separation into MVP/MVC type pattern for a project I am working on.

Simple Background on Project:

– Vaadin 7 based
– Using JPA (and specifically JPA Container) w/ Hibernate (not that it makes a difference for the question).

Here is the issue I am about to tackle, and just don’t want to create a LOT of work for myself. :slight_smile:

As part of the application, the main Entity the application is based around needs to be displayed. I already have a nice table/search thing going, so that’s fine…

However, this Entity (let’s call it Detainee) has a very complex ERD associated with it, involving not only lookup table values for various fields (sex, gender, etc) but a TON of relationships – both One2One and One2Many, etc.

I need to show all the information about a single detainee – the existing system (Desktop App) does this by having a “window” that has 15 different tabs – each tab showing a major part of the overall record set. There is a tab with all the basic information, and then basically a tab for each “relationship” off the main Entity. Each tab itself contains a LOT of fields – the main one has 70 or so, the others about the same or less. And of course, the client wants to show the fields in a “pretty” layout, with formatting of appropriate fields, etc.

My first proof of concept (for the main data tab) is that I passed in from the “List Table” to the main show form, the POJO of the main Entity – and then converted that to a BeanItem and then used a FieldGroup and finally a grid layout (set to an arbitrary 7 columns) and looped through the propertyid’s and did an “addComponent” with a “buildAndBind”.

Well, that dumped out a bunch of information but in no way did it look “good” and I had the following problems:
– Some propertyIds should just not be shown (business logic only)
– Some needed formatting (2 types of different date formatting)
– Some needed a bigger size “text” box to display the info
– Some needed to be renamed
– The layout order was alphabetical, and certainly not in the order the customer wanted.

Now, if this were just a few fields I could see maybe “hand coding” the layout – but this is 15 tabs, each with 50+ fields!

Is there a good pattern for such things? How do people layout “real” forms (i.e. from a real-world complex model) that can handle this w/o hand coding each property?

Also, is passing the POJO a good idea? I’m thinking since I have a JPAContainer item that’s selected, I should just pass an Item thing around and feed that into the FieldGroup?

Oh – and of course, I’d like this to be I18N so the Label/Caption names are looked up. :slight_smile:

More desires: If the user stretches the screen, the fields and spaces between nicely expand . If they shrink the window the reverse, until we need scrollbars …


I’ve looked at what I think are possible Add-ons but nothing exactly pops out – maybe because I haven’t chosen a “pattern” yet.

Any thoughts, help, etc. would be appreciated!


We have similar questions about a somewhat common scenario we have with variable types a given Form. That is, we have a Form to configure an item, but the item varies depending on its “type” – which is generally set via a NativeSelect.

As a simple example of just a choice between Male and Female, when Male is chosen, it might show several form fields that are specific to males only, and if Female is selected, it might show many similar fields, but perhaps a few that are different.

We’re looking for best practices on how people handle such Forms where the fields vary depending on a primary selector.

Hi Steven,

that is a very interesting topic. I am also creating a quite complex application with quite an amount of fields.
To summarize it:

  • Complete automatic layouting of all field from a Pojo was my first thought and never worked out :slight_smile:
  • I ended up building my own framework (including container) to have a simple and flexible approach for creating fields for a JPA annotated pojo. This was partly because the JPA container was not ASL at this time and I am using also a lot of JavaEE Services for the CRUD operations.

Because I love open source, I separated the framework code from the business logic and open sourced the first one. You can find it here:

One of the central parts is to have a quite intelligent FieldFactory that creates the right Vaadin field for an entity attribute. The JPAContainer has this and I had built my own. To be flexible enought for kind of UI tweeking, I ended up with the following structure:
There is a DefaultFieldFactory (
) which takes the attribute type and the JPA annotations to find out what to build. Then there is a FieldCreator (see
) for each field type (e.g.
) to configure the field according to the annotations (like length etc) and a FieldSpecification. A FieldSpecification (
) is an optional way to customize the field appearance (with custom width or height or anything). The DefaultFieldFactory can be extended by creating a CDI bean implementing a FieldFactory interface for providing more specialized fields.
To create a field the minimal thing is to give the name (or only the entity class, but that did not work see my first point) and the framework does the rest. But the layout of each field can still be adjusted in multiple ways. The form layouting is then done by a GridLayout with giving each field a Label on the left side. You can find a simple example for here:

Perhaps that gives some ideas.


Thomas – that indeed sounds just what I was looking for/thinking too. Well done! I plan to take a peek at your work and happily plagiarize whatever I can. :slight_smile: