Community
Participate
Working Groups
3.3 With a decoration context, it is possible to let decorators react on viewer specific characteristics. The package explorer for example has two modes showing packages: Flat or hierarchical. Decorations that summarize the state of all children (e.g. problem decorator, CVS decorator) need to know what children the given element has. CVS solved this by specifying a IDecorationContext property called SynchronizationStateTester.PROP_TESTER. If this property is set, it will be used instead of the default SynchronizationStateTester. The package explorer label decorator offers a modified SynchronizationStateTester when in hierarchical mode. It does nothing else that providing an alternative ResourceMapping for IPackageFragment's SynchronizationStateTester is specific for team's needs. We should generalize this so all other similar decorators can also be hierarchical mode aware. Suggestion is to define offer a alternative resource mapper class ResourceMappingProvider { public final String RESOURCE_MAPPING_PROPERTY= "ViewerResourceMappingProvider"; abstract ResourceMapping getResourceMapping(Object element); } DecorationContext.getProperty(RESOURCE_MAPPING_PROPERTY) returns a instance of ResourceMappingProvider. The package explorer will provide a ResourceMappingProvider that returns ResourceMappings that are hierarchical mode aware This extension would then also be used by JDT/UI for the problem decorator. It could also be used by the default SynchronizationStateTester, so that JDT UI doesn't need provide the property SynchronizationStateTester.PROP_TESTER. A more generic alternative is to avoid a new type but use IAdapterFactory. This could even be done in all in JFace. IDecorationContext: String ADAPTER_FACTORY_PROPERTY= "AdapterFactory"; Client code: factory= (IAdapterFactory) context.getProperty(IDecorationContext.ADAPTER_FACTORY_PROPERTY) if (factory != null)) { ResourceMapping mapping= (ResourceMapping) factory.getAdapter(element, ResourceMapping.class) The alternative is to have JDT UI provide a JDT UI specific IDecorationContext. Problem with this is that resource decorators like the CVS decoarator are not JDT aware.
Tod, wouldn't this be better classified as [Decorators]?
No - this change is not going to be in the decorator support but in label providers if I am not mistaken. Martin or Michael could you please clarify?
Maybe even IDE... There are several approaches on where this would go: suggestion a.) would probably be in IDE , as it depends on JFace and resource. Could also be Team? suggestion b.) would be in JFace Or maybe we find a completely different approach...
To summarize, what you are asking for is that any hierarchy based decorators use the structure of the model as it is displayed in the view instead of the actual structure of the model. I would put forward that the scope of this request is too narrow. If we want the decorations to match the dispaly structure, then we should also have a mechanism whereby the operations performed on the elements in the view should also match the display structure. Such a mechanism should be available to the decorators and any object contributions that appear in the view. Having decorations match the display structure and operations match the underlying model structure is very confusing for users.
Hitesh is now responsible for watching bugs in the [Viewers] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
