In the HbnContainer incubator example, there is a ManyToOne association that is shown as a combo box, and a ManyToMany association that is shown as a drop-down.
But I was surprised to find that the ManyToOne association requires custom code to display the title of the linked object, and a field factory to generate a drop-down. Given that the container already knows that the property is an association, this shouldn’t be much harder than handling a Date field, right ? (I know this is naïve, having done similar scaffolding myself in another life, but it sure would be useful). The multi-select case is downright ugly (I’ve figured out a way to show a comma-separated list of items, but am still figuring out how to do it in a more general way)
p.s. can’t wait for the proposed JPA container - it would be wonderful if it worked both with GAE and regular databases !
This answer comes rather late, but better late than never. The main author of HbnContainer (Matti) might be able to say more when he returns from his vacation.
The generic Vaadin interfaces Container, Item and Property do not and should not know if underneath, a property corresponds e.g. to an association in a database. Thus, while the container itself knows which properties are associations, the table component (or any other component displaying the information) does not.
If such awareness is needed, subinterfaces could be created, but this requires careful design to obtain a sufficiently generic solution.
Furthermore, even if a property could be automatically recognized as an association, it is not obvious how the possible target objects should be retrieved and displayed. There could even be properties that are logically associations between a database and some other data source.
Nevertheless, basic tasks could be made much simpler.
I quickly refactored the HbnContainer example to generalize the field factory somewhat, creating an AssociationFieldFactory base class in the demo. It encapsulates the ugly details of combo box or list creation etc., letting the user simply declare the property identifiers, corresponding containers and editor types to use. However, it still suffers from the problem of the old example that editor components are cached indefinitely once created, and could also be cleaned up otherwise. Feel free to improve it (and send us patches) if you find it useful.
(I know this is naïve, having done similar scaffolding myself in another life, but it sure would be useful). The multi-select case is downright ugly (I’ve figured out a way to show a comma-separated list of items, but am still figuring out how to do it in a more general way)