Comments RE Vaadin data API

Recently I’ve been doing a lot of work with the Vaadin data API and wanted to submit some comments for consideration. On the whole, the design is excellent. Properties and Items are nice to use, so much so that I’ve converted some of my internal datatypes to Property and Item formats, which I also thought would make it easier to work with Vaadin. Instead it makes things harder. I find that Containers, while very powerful, are the confusing and unintuitive part of the API.

When you add an Item to a container, intuitively one would expect that you actually could pass an Item to the container to be added to the container. Instead you pass an Item ID and a blank internal Item gets created, the properties of which need to be updated. You have now severed the link between the data type (which, if it was converted to Property / Item format, already had properties).

What is really needed is an ItemContainer that actually lets you add Items and Item Ids.

The BeanItemContainer might serve this purpose except for the restriction that equals and hashcode cannot depend on any part of the bean that can be modified. For most purposes, this just doesn’t work. How else are you going to figure out if two beans are equal except by the values of their properties.

Another complication is that once you’ve copied item properties into the item in the container, there is no direct link to changes in property datasources. You can get notified whenever a field value changes but it only actually changes the datasource in writethrough mode. However, one may not want writethrough mode if the user may make potentially many changes (e.g. through a TwinColSelect) and each change results in a database write.

A final addition to the api that would be useful, but possibly hard to implement is an ItemBean as opposed to a BeanItem. Like a BeanItem takes a Bean and converts it to an Item, this would take an Item and allow the user to interact with it like a bean. I tried this myself using Apache Commons DynaBeans but didn’t manage to get it working.

Hope you take these comments in the constructive spirit in which they were intended, as I am a big fan of Vaadin.


Hi Jonathan,

Thanks for your comments. I think we can take you in constructive sense :slight_smile: The guys at core development are listening.

I just wanted you to know that you are not alone with this:

Right. In this sense BeanItemContainer is complicated for simple use cases. For example bean collections that can have duplicates.

To solve these kinds of use cases I created the

It offers few indexing options to bind collections of Java beans:

  • Use collection index of items as id
  • Use property value as item id (bean’s unique id property)
  • Automatically create new unique ids for objects
  • Use objects in collection itself as item id (like in BeanItemContainer)

For lists using index as id is much more intuitive than messing with the object equals/hash codes. Also having an id property in the beans was/is very typical scenario and I needed to support that one.

I know that effectively separating the bean and id is not as scalable approach (at least in theory). But I haven’t seen any real-world performance problems and in many simple cases this is much more intuitive.