| [Databinding] Unnecessary limitations of ComboObservableValue? [message #309518] |
Mon, 30 October 2006 07:30  |
Eclipse User |
|
|
|
Hello,
recently there was a thread comparing jface.databinding with other
existing binding frameworks, e.g. with Karsten Lentzsch's data binding
from jgoodies found at
https://binding.dev.java.net/
Currently we do indeed use the later one, but would like to switch
to jface.binding in a future product release.
One very advantage of the jgoodies approach is that although there
exist type-checking facilities, the binding is not strictly bound to
that type. Let me explain that a little bit further: Most SWT
widget's have a String type target, which makes sense, but the Combo
family also has the concept of a selection. Regrettably the current
implementation of ComboObservableValue uses the immediate cast
from Object to String instead of the toString route:
if (index == -1) {
combo.setText((String) value);
} else {
...
}
Consider that we have a Mapper class, which e.g. contains some
kind of enumeration and has capabilities to map each enumeration
into a proper String. Furtheron this enumeration class has its
own equality check (e.g. via its equal method, but that is not a hard
constraint), which we would like to use (it might use uuids-comparisons
or something like that). How can we enforce the ComboObservableValue
to use the corresponding comparison (under the hood) instead of
raw String comparisons?
The jgoodies library has a very useful concept of something known as
"SelectionInList" which effectivly allows to use any arbitrary
"intelligent" selection holder to decide which items are considered to
be equal. Is something similar possible with jface.databinding? What is
the recommended way to go realize such a task (without writing my own
binding)?
Greetings from Bremen,
Daniel Krügler
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03125 seconds
Home