editable table vs bindings

I have an editable Table. In a generated column, I add an Edit button on each row. The Edit button opens a subwindow, in which there is a Form, for which the data source is the Item I clicked on. I also override setItemDataSource because I don’t want all of the properties of the bean that underpins the Item :

    public void setItemDataSource(Item newDataSource) {
        if (newDataSource != null) {
            List<Object> orderedProperties = new ArrayList<Object>();
            /* ... */
            super.setItemDataSource(newDataSource, orderedProperties);
        } else {

When I click OK in my subwindow, a commit is made, and everything works, except that the values in the Editable table are not updated. I have looked briefly at the super.setItemDataSource() source code, and from what I can tell, the same Property objects are being used.

What am I missing ? I currently have toggle editable mode off and on to get a refresh – the editable table seems blissfully unaware that its item has been messed with.

If you have put beans in a Table, you probably use either CollectionContainer or BeanItemContainer. The former is problematic in many ways; when you need to add new items to the collection, you have to recreate the container. The latter is therefore recommended.

Remember to use the same BeanItem wrapper in the editor form as you use in the table. If they are separate, the value changes to the BeanItem in the form are not communicated to the table. This is because the underlying bean does not (and can not) tell its BeanItem wrapper(s) that it has changed.

For an example, see:






[/list]You can
run the app
to see how it works. Use demo/demo for some example data.

My container is an HbnContainer, actually.

But the code seems to contradict your advice.

At line 101 of UserView.java, editCar is called with the underlying Pojo (the Car).
At line 70 of CarEditor.java, a new BeanItem is created to wrap the Pojo.

Also, in the Car example, the table is not editable (i.e. cells do not contain fields). Are editable tables with fields meant to update like they would if there were properties inside ?

You’re right, in that case the BeanItems are separate, so the car data are not updated automatically in the car table after editing. In such case, it’s necessary to call the [tt]
[/tt], which rebuilds the table (creates an entirely new container from scratch and binds it to the table). It’s not a big effort to rebuild it, and you need the method anyway to populate the table initially, but it’s not as efficient as updating just the changed item. With this small data, not a big deal.

The CarView/FillEditor pair was actually done that way earlier as well, but I think the current solution is a bit more elegant in how it uses the data binding. Oh well.

HbnContainer might need a different solution, I haven’t used it myself.