* This is the functional opposite of {@link IRemoteObjectResolver}. *
* - * @see IRemoteObjectIdentifier + * @see IRemoteObjectResolver */ public interface IRemoteObjectIdentifier { /** - * Return a String ID for the given remote object, that is unique - * within the subsystem. + * 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 - * {@link IRemoteObjectResolver#getObjectWithAbsoluteName(String)}. - *
- * 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 - * {@link IRemoteObjectResolver#getObjectWithAbsoluteName(String)} - * method actually finds the object by the given ID. Other subsystems - * do not need to be considered. + * 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 + * {@link IRemoteObjectResolver#getObjectWithAbsoluteName(String, IProgressMonitor)}. *
- *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 {@link 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.
+ *
+ * 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. *
- *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:
+ *
+ * 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 + * {@link 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
+ * {@link 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:
*
null.
+ * @return a String uniquely identifying the remote object within the
+ * subsystem. Must not return null.
*/
public String getAbsoluteName(Object object);