Binding multiple UI elements to the same model

Hello everyone,

I’m currently exploring the Vaadin databinding API (Properties, Items & Containers). Everything looks very well designed from what I have seen so far in terms of API. However, today I came across a detail that made me wonder why it is done that way.

There is a famous pattern in UI programming called Model-View-ViewModel (MVVM, see
http://de.wikipedia.org/wiki/Model_View_ViewModel
). Vaadin’s "
Property
" class seems to pretty much take the role of the ViewModel in the MVVM pattern. It has a “setValue” and “getValue” method that hides implementation details from the UI elements that operate on the data.

However (and now that’s what I find odd about it) the "
addValueChangeListener
" and "
removeValueChangeListener
" methods are
NOT
defined by Property itself, but rather by "
ValueChangeNotifier
" (which is unrelated to the Property interface with respect to the inheritance hierarchy). My question is simple:
why
? This is a great obstacle when implementing MVVM in the case of multiple UI widgets that work on the same model.

For example, imagine a typical master-detail editor: a list of elements displayed by a table, and by selecting an element in the list you get an editor for the element details. The table and a text field in the details editor both allow you to change the name of the element. However, since Property does not offer to add change listeners to it, the table will not receive an update via the Property when it is changed in the text field, and vice-versa. This update would need to be executed by the application itself (i.e. call some “refresh contents” method on both UI widgets).

Am I missing something here or is this really the case? I’m kind of confused by that right now…

Thanks,

Martin

Okay, I think I’ve found an explanation… sort of. Take a look at the following lines of code:

private void addPropertyListeners() { if (!isListeningToPropertyEvents) { if (dataSource instanceof Property.ValueChangeNotifier) { ((Property.ValueChangeNotifier) dataSource).addListener(this); } if (dataSource instanceof Property.ReadOnlyStatusChangeNotifier) { ((Property.ReadOnlyStatusChangeNotifier) dataSource) .addListener(this); } isListeningToPropertyEvents = true; } } These are found in Vaadin’s
AbstractField
. That’s pretty much the explanation to my question above. Vaadin widgets do not assume a Property to be observable, but they CHECK for it via
instanceof
. This is documented in the JavaDoc of the Property.ValueChangeNotifier.

While I can see what was intended here (hiding the listener methods from implementations that don’t deal with them), to me this is a rather… awkward way of doing it. An interface which extends Property and offers the listeners would have been more obvious. Checking instanceof and casting to a subclass is a bit more tolerable imho than doing it for an unrelated class/interface.