Bug 183031

Summary: [DataBinding] Ability to control label text in ObservableMapLabelProvider
Product: [Eclipse Project] Platform Reporter: Peter Centgraf <peter>
Component: UIAssignee: Matthew Hall <qualidafial>
Status: RESOLVED DUPLICATE QA Contact: Matthew Hall <qualidafial>
Severity: enhancement    
Priority: P2 CC: bokowski, bradleyjames, mallo.ovidio, qualidafial, rancidfishbreath, s.becher, tom.schindl
Version: 3.3   
Target Milestone: 3.6   
Hardware: All   
OS: All   
Whiteboard:

Description Peter Centgraf CLA 2007-04-18 14:50:07 EDT 
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().
Comment 1 Brad Reynolds CLA 2007-04-18 15:08:59 EDT 
(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.
Comment 2 Matthew Hall CLA 2008-04-11 11:47:22 EDT 
 (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.
Comment 3 Boris Bokowski CLA 2008-05-02 14:57:02 EDT 
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.
Comment 4 Philip Borlin CLA 2008-08-09 14:40:36 EDT 
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?
Comment 5 Boris Bokowski CLA 2008-08-09 14:54:48 EDT 
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.
Comment 6 Sascha Becher CLA 2010-02-24 09:55:24 EST 
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.
Comment 7 Matthew Hall CLA 2010-02-24 18:29:27 EST 
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.
Comment 8 Matthew Hall CLA 2010-02-25 00:26:33 EST 
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 ***