Community
Participate
Working Groups
The current (as of 3.3 M6) label provider implementations provided with DataBindings do not fully leverage the available API in two cases: 1. ListeningLabelProvider and ObservableMapLabelProvider both render Strings via a basic toString() call. This should use an IConverter instead. OMLP should have an array of IConverters -- one for each column. This could be extended to have separate converters for Text and Image (on each column). 2. ListeningLabelProvider could take an IObservableFactory parameter and eliminate the need for subclasses to implement addListenerTo() and removeListenerFrom().
(In reply to comment #0) > 1. ListeningLabelProvider and ObservableMapLabelProvider both render Strings > via a basic toString() call. This should use an IConverter instead. OMLP > should have an array of IConverters -- one for each column. This could be > extended to have separate converters for Text and Image (on each column). As a workaround until we can introduce new API (3.4) the consumer can extend the class and implement this with or without converters since this class is public and open for extension.
(In reply to comment #1) > As a workaround until we can introduce new API (3.4) the consumer can extend the > class and implement this with or without converters since this class is public > and open for extension. It's not quite open enough to be useful. Subclasses can override getColumnText() where they will get a reference to the element. However without access to the attributeMaps field (which is private) there's no way to access the specific attribute of the element. In my own workspace I've extracted the toString() portion of getColumnText to protected toString(Object elementAttribute, int columnIndex) method, which can be overridden in subclasses. This bug seems to be a dupe of 126978.
Mass update - removing 3.4 target. This was one of the bugs I marked for investigation (and potential fixing) in 3.4 but I ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
This may not be the best place to discuss this, but I didn't want to open a new bug just to ask this question. Shouldn't the ContentProvider be in charge of listening for changes while the LabelProvider just provides labels? In other words shouldn't the listening functionality be in ObservableListContentProvider and ObservableSetContentProvider?
I don't think so - how can the content provider know which attributes to listen to? Another indication is that IBaseLabelProvider (available since 1.0) defines an addListener/removerListener API that would be of no use if label providers were completely passive.
This is still a problem. ObservableMapLabelProvider isn't made for subclassing since the field 'IObservableMap[] attributeMaps' is private and final. Not all properties are displayed by .toString() nor is it favourable to override toString() in order to localize an enum. Please change the importance of this bug. This isn't just an enhancement.
Taking ownership. I agree 100% with you, and will try to make some time soon to fix this. Technically, enhancement is the correct severity, however I'll raise the priority to P2.
Dupe of 302860. Marking this as a dupe since I posted a patch on the other bug by mistake. *** This bug has been marked as a duplicate of bug 302860 ***
