Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

RSE
Release 3.0

org.eclipse.rse.core.subsystems
Interface IRemoteObjectIdentifier

All Known Subinterfaces:
ISystemDragDropAdapter, ISystemRemoteElementAdapter, ISystemRemoteObjectMatchProvider, ISystemViewElementAdapter
All Known Implementing Classes:
AbstractSystemViewAdapter, SystemViewRemoteOutputAdapter

public interface IRemoteObjectIdentifier

Interface that remote objects must implement in order to be identifiable for drag and drop, clipboard support, and finding multiple occurrences of the same remote object in different contexts in the SystemView.

This is the functional opposite of IRemoteObjectResolver.

See Also:
IRemoteObjectResolver

Method Summary
  String getAbsoluteName ( Object object)
          Return a String ID for the given remote object, that is unique within the subsystem.
 

Method Detail

getAbsoluteName

String getAbsoluteName(
Object object)
Return a String ID for the given remote object, that is unique within the subsystem.

This must be implemented by subsystem element adapters in order to marshal a reference to the remote object for drag and drop, and clipboard support. It is also used for uniquely identifying objects with changing properties in the SystemView. This method is the functional opposite of IRemoteObjectResolver.getObjectWithAbsoluteName(String, IProgressMonitor).

The unique ID for an object must remain the same over the entire lifetime of that object, such that it can always be identified. When an object is renamed, it should be removed from the views with the old ID and then re-added with the new ID. This is especially important for the SystemView, where the String ID is used for finding multiple occurrences of the same remote resource in different contexts during refresh events. In this case, the String ID can be used to find the remote object even if its hashCode changes due to updated properties. So even if a subsystem does not support drag and drop, or clipboard operations, it does need to return unique IDs for its object to support refresh in the SystemView.

Because each subsystem maintains its own objects, it is the responsibility of the subsystem and its adapters to come up with a mapping that is unique for the subsystem. Some subsystems use fully qualified path names, while others may use other methods. Extenders just need to ensure that objects of different type (such as filters, actual resources or error messages) all have different IDs within the subsystem, and the corresponding IRemoteObjectResolver.getObjectWithAbsoluteName(String, IProgressMonitor) method actually finds the object by the given ID. Other subsystems do not need to be considered.

Uniqueness and Multiple Contexts
The RSE SystemView allows the same remote object to be displayed in multiple different contexts, i.e. under multiple different filters. In this case, each occurrence of the same object must return the same absolute name. For the reverse mapping, however, it is up to the subsystem whether its IRemoteObjectResolver returns only one internal model object for the given identifier, or multiple context objects which all refer to the same remote object but also hold context information.

Examples
In the File Subsystem, a fully qualified pathname is used to uniquely identify remote objects. For other kinds of objects maintained by the same subsystem, the following schemes are used:

  • The subsystem itself is identified as
    subsystemID ::= (profileName).(connectionName).(subsystemName)
    - see SystemViewSubSystemAdapter
  • Filter Pool References are identified as
    filterPoolID ::= (subsystemID).(poolManagerName).(poolReferenceName)
    - see SystemViewFilterPoolReferenceAdapter
  • Filter References are identified as
    filterRefID ::= (filterPoolID).(filterName)
    - see SystemViewFilterReferenceAdapter
  • Search Results are identified by the IHostSearchResult.SEARCH_RESULT_DELIMITER embedded in the ID.
All these IDs for internal elements like the subsystem itself or the filters start with a profile name which must not contain any of the / \ or : characters. Fully qualified path names, on the other hand, always start with a / or \ character (UNIX style paths, Windows UNC paths) or have a : character on the second position (Windows drive letters). The SEARCH_RESULT_DELIMITER is ":SEARCH" which cannot be part of a valid filename. Therefore, this naming scheme is guaranteed to be unique.

Parameters:
object - the remote element to be identified.
Returns:
a String uniquely identifying the remote object within the subsystem. Must not return null.
See Also:
IRemoteObjectResolver.getObjectWithAbsoluteName(String, IProgressMonitor)

RSE
Release 3.0

Copyright (c) IBM Corporation and others 2000, 2008. All Rights Reserved.

 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire