ListProperty and ListBinding

Michael Heinrichs Michael.Heinrichs at
Mon Dec 19 04:06:57 PST 2011

Hi Gaja,

answers inlined.


On 16.12.2011, at 12:43, Gaja Sutra wrote:

> Will ObservableListValue.{add|remove}Listener(InvalidationListener) [coming from Observable interface] be processed following contract of ObservableObjectValue<ObservableList<E>> [change of list in this ObservableListValue<E>] or following contract of ObservableList<E> [change in contents of the list in ObservableListValue]?

That is a very good question and I am surprised I did not mention this in the proposal. All listeners will fire in all cases, because that is what you usually want to get notified about. In more detail:

InvalidationListener is simply fired, if the reference might have changed or the content of the list might have changed.
ChangeListener is fired as usual, if the reference changes. If the content of the list changes, it is also fired, but oldValue and newValue point to the same list. In other words a quick comparison can help you distinguish between both cases, if you need it.
ListChangeListener is fired as usual, if the content of the list changes. If the reference to the list changes, it is fired as if the whole content was replaced.

>> [...]     public static void unbindContentBidirectional(Object obj1, Object obj2) {...} 
> Static methods added to Bindings does not specify in their name the (Observable)List target of content binding (unlike some name like "(un)bindListContentBidirectional").
> Will it be a problem, given than List is an interface and a specific class can implement multiple interfaces, then multiple types of bindings? [it's only a question].
> I currently don't find any realistic use-case, but supposing we have two objects, each implementing List and Map, and we want to bind/unbind together only as List or as Map, we can have a problem with current names.
> Preceding ObservableListValue is an example of an object having two Observable natures (ObservableObjectValue and ObservableList). Another example can be a SVGPath being a String and a Shape: binding together two paths can be made at String or at Shape level.

Interesting point. Have not thought much about the question, if this could be ambiguous in certain cases. First of all, we can only unbind what was bound before, which means we do not have to deal with combinations like ObservableObjectValue vs. ObservableList or String vs. Shape.

I think usually we do not run into issues. We are trying to unbind two objects, so even if one of them implements several interfaces, we are able to find the exact binding via the second object. Now an interesting question is, if both objects implement say ObservableList and ObservableMap, what are we going to do in that case? I think we should just unbind all content-bindings between them in this (rather exotic) case.

More information about the openjfx-dev mailing list