Community
Participate
Working Groups
Build ID: e33m5, rse20m5 Steps To Reproduce: ISubSystemConfigurationAdapter.getSystemFilterImage() and ISubSystemConfigurationAdapter.getSystemFilterPoolImage() should get the references for filter and filter pool to know the context instead of the filter and the filter pool. knowing the context (subsystem, host) is needed to decorate the filter and/or filter pool according the subsystem and/or host where this filter (pool) is placed. More information:
Marking as API change - Dave can you comment on this please: I agree that when returning an image for a filter or filter pool, in order to properly decorate it with status information it is important to know the context (of the ISubSystem) that the filter is used in. I'm wondering whether it would be possible to pass in an ISystemFilterReference / ISystemFilterPoolReference instead of the ISystemFilter / ISystemFilterPool? The Reference objects would hold information about the filter as well as the context. Proposed change OLD: ImageDescriptor getSystemFilterPoolImage(ISystemFilterPool filterPool); ImageDescriptor getSystemFilterImage(ISystemFilter filter); NEW: ImageDescriptor getSystemFilterPoolImage(ISystemFilterPoolReference fpRef); ImageDescriptor getSystemFilterImage(ISystemFilterReference fRef);
FYI: It looks like currently, when the image is actually needed: 1. the SystemView finds a FilterReference; 2. the SystemViewFilterReferenceAdapter finds the filter 3. the filter is adapted to an ISystemViewFilterAdapter 4. the ISystemViewFilterAdapter asks the SubsystemConfigurationAdapter for the image We propose to streamline the process, such that in (2) the FilterReferenceAdapter directly asks the SubsystemConfigurationAdapter for the image to use with the reference. What I am not sure about is, whether it is possible to get rid of the method that returns an image for the actual filter. Where would a SystemViewFilterAdapter actually be used? Aren't we using filter references everywhere?
I guess, up until now, we never cared about context information for images of filters. Using filter reference (with the additional context information) seems reasonable although one thing we should check before doing this is what gets called from the team view (since we have no context for the objects in there).
Right. We might end up having to provide both "OLD" and "NEW" variants. A default implementation for the "NEW" variant in SubsystemConfigurationAdapter could get the filter out of the filterReference and call the getSystemFilterImage() method with it. Then, implementors which do not care about the context do not need to change and it's a non-breaking API change.
I've added the proposed APIs while keeping the originals. The default implementation in SubSystemConfigurationAdapter is as follows: /** * Supply the image to be used for filter pool references. This implementation * just gets the referenced filter pool and calls the method * getSystemFilterPoolImage(ISystemFilterPool) on it. * Override this method to provide custom images for filter pool references. */ public ImageDescriptor getSystemFilterPoolImage(ISystemFilterPoolReference filterPoolRef) { return getSystemFilterPoolImage(filterPoolRef.getReferencedFilterPool()); } /** * Supply the image to be used for filter references. This implementation * just gets the referenced filter and calls the method * getSystemFilterImage(ISystemFile) on it. * Override this method to provide custom images for filter references. */ public ImageDescriptor getSystemFilterImage(ISystemFilterReference filterRef) { return getSystemFilterImage(filterRef.getReferencedFilter()); }
[target cleanup] 2.0 M6 was the original target milestone for this bug
