Description Heiko Böttger 2012-07-26 13:31:51 EDT

Build Identifier: M20120208-0800

The current code in the NavigatorContentService just uses any LabelProvider that might be related to an element:

public StyledString getStyledText(Object anElement) {
		Collection extensions = contentService.findPossibleLabelExtensions(anElement);
		if (extensions.size() == 0)
			return new StyledString(NLS.bind(CommonNavigatorMessages.NavigatorContentServiceLabelProvider_Error_no_label_provider_for_0_, makeSmallString(anElement)));	

		StyledString text = null;
		for (Iterator itr = extensions.iterator(); itr.hasNext() && text == null; ) { 
			text = findStyledText((NavigatorContentExtension) itr.next(), anElement);
		}
		return text != null ? text : new StyledString();
	}

I found a bug in my LabelProvider implementation where i wasn't expecting to receive element from another connentprovider (JavaNavigatorContentProvider). I wasn't expecting this, because there is no PipelinedLabelProvider interface and the javadoc on the ICommonLabelProvider says nothing about this. 

In short the whole thing means that one have always to provide his own object-type, otherwise it gets difficult to find out which element to handle. 

I propose to handle this in the CommonNavigatorFramework itself by remembering which ContentProvider actualy returned the element by its getChildren/getElement method. Decorating could be handled by a special method on the PipelinedLabelProvider.

At least ther should be a warning on the ICommonLableProvider interface. The note to refer to the "org.eclipse.ui.navigator.navigatorContent" extension point is not enough.

Reproducible: Always

Steps to Reproduce:
1. Define a NavigatorContent which accepts elements adaptable to for example IResource
2. add a Labelprovider using Object.toString() or delegating to the WorkbenchLabelProvider