If I have a BeanFieldGroup I can bind fields and properties of a POJO together fine so that the changes propagate to the POJO but what would be the equivalent in the collection level?
I can do a
Collection<String> strings = IntStream.range(0, 6).mapToObj(i -> String.format("Item%d", i))
.collect(Collectors.toList());
System.out.println(strings.size());
BeanItemContainer<String> bic = new BeanItemContainer<>(String.class, strings);
System.out.println(bic.removeItem(bic.getItemIds().iterator().next()));
System.out.println(strings.size());
but the output is
6
true
6
which means that the items have just been added to the BIC and live a life of their own from there on. What would be the way of binding the collection so that if I remove an item from the BIC (e.g. a delete button in a table) the row is also automatically removed from the collection?
I don’t think Vaadin supports two-way binding like what you are thinking. Once you remove the item from your BeanItemContainer, you are going to have to query the BeanItemContainer. The changes to the BeanItemContainer are not going to propagate back to your original collection.
Do this instead and you should see an output of 5:
System.out.println(bic.size());
One would think that it would be a quite useful scenario too keep the model and the view synchronized even with collections. A Table would be backed by a BeanItemContainer and a FieldGroup would bind the table to the collection attribute of the model and Stuff Would Just Work™
BeanItemContainer doesn’t (and shouldn’t) assume the nature of the underlying model. It could be that the model is a standard
Collection implementation, a custom implementation, or any other Java type. A
Collection is used merely to pass the POJOs that the
Container should contain. But it’s just that, a mechanism to pass several POJOs to the
Container so that you are free to use any types to implement the model.
I usually think of a
Container as a UI concept (yes, there is a
JPAContainer , but I never use it ). In the case of
BeanItemContainer , I see it like a helper class or intermediary to pass POJOs (such as
Customer ,
Product , etc.) to the UI component.
From the UI developer perspective, when a
command in the UI instructs the app to remove an
item from somewhere (like in your case), you have to invoke the back-end to remove the item (business logic) and tell the UI to either remove the item from the screen or update itself (probably reading the data set again and re-generating the corresponding part of the UI). I’ve seen this last aproach (update the UI) in several projects. It’s easy to understand and therefore to mantain.
). In the case of