Community
Participate
Working Groups
Comparing two objects by absolute name is an operation that's supposedly needed more frequently. We should put it in a common location, at least "internal" for 2.0.1 if not API for 3.0.
This is created because of bug 192716. The comparison code should be in the patch of that bug.
Dave what do you think would be a good common place for comparing two objects by absolute name?
I would think that SystemRegistry would be an appropriate place, although it's interface, ISystemRegistry is public. Would it make sense to put it in the implementation without the interface initially (i.e. for 2.0.1)?
Hm... the SystemRegistry is so filled with functionality already... also, the SystemRegistry implementation should be non-UI eventually, and if I'm not mistaken the compare code will need ISystemViewElementAdapter which is UI (though it might also work with IRemoteObjectIdentifier which is non-UI). I had first thought about SystemAdapterHelpers, but perhaps keeping everything non-UI is indeed the better solution, is this possible?
Hmm.. I guess the adapters would be the most obvious way to do the comparison since we don't provide any other extension that allows new model objects to provide info about themselves. IRemoteObjectIdentifier has the right API for this but not all objects use it. SystemAdapterHelpers is really just there to help returning appropriate adapters for objects so it wouldn't seem like the ideal place. I was thinking of system registry because it's got some related functionality such as getRemoteResourceAbsoluteName() and getAbsoluteNameForSubSystem().
Ok, then let's put it in the SystemRegistry impl, next to the methods you mentioned and provided that we can do it with non-UI dependencies only. I think that IRemoteObjectIdentifier should be sufficient because ISystemViewElementAdapter (ultimately) derives from IRemoteObjectIdentifier.
See also bug #195537 asking for moving the ElementComparer out of the SystemView -- this could perhaps also make use of a utility class for comparing objects by absolute name
Created attachment 73269 [details] fix for bug 194838 Move the comparison code to SystemRegistry. . Since there is no getSubSystem() method in IRemoteObjectIdentifier, so use ISystemDragDropAdapter instead (which is not in a UI package). . Since no API change in ISystemRegistry interface, we need to cast the resullt of RSECorePlugin.getTheSystemRegistry() to SystemRegistry so that the new method could be called. Legal Message: I, Xuan Chen, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
I've put Xuan's changes in cvs. Thanks Xuan!
This leads to NPE's b/c of: String subSystemId = getAbsoluteNameForSubSystem(subSystem); where subSystem is null.
I just noticed this problem too. If you use a host as the input to the view this can be hit when an event comes in.
(In reply to comment #8) Thanks for the patch. I'm not too fond of using ISystemDragDropAdapter but I can see there is currently no way around it. I filed bug #195836 asking for an API change in 3.0 to push getSubSystem() up into IRemoteObjectIdentifier, where I think it belongs.
Created attachment 73338 [details] Fix the NPE reported by Kevin Legal Message: I, Xuan Chen, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
I've committed the update for this.
Please don't forget to add the "contributed" keyword as soon as a patch from a non-committer is checked in to CVS. Thanks!
oops...I gotta get into this habit!
The Change is good. Just one little word of caution: When the SystemRegistry implementation is eventually moved from UI to a non-UI plugin, access to the "internal" method isSameObjectByAbsoluteName() will require opening access to the plugins that need it via the x-internal clause. Or, since this can only happen in the 3.0 stream, add public API for the isSameObjectByAbsoluteName() method.
This problem is fixed.
