From e880c37f72459f84e1859a10df20db07fb8a165f Mon Sep 17 00:00:00 2001
From: David Dykstal
Date: Mon, 9 Jun 2008 17:11:50 +0000
Subject: [PATCH] [193747] [Doc] Dead Link on Plugging In SubSystems page for
extension markup https://bugs.eclipse.org/bugs/show_bug.cgi?id=193747
---
.../guide/plugin/subsystem.html | 63 +++++++++----------
1 file changed, 30 insertions(+), 33 deletions(-)
diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html b/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html
index d601e1b06de..5b0ff5ad44d 100755
--- a/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html
+++ b/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html
@@ -4,7 +4,8 @@
-
+
+
Plugging In SubSystems
@@ -19,34 +20,34 @@ a connection when a connection is expanded in the Remote Systems view.
For example, here is an iSeries connection with four subsystems,
each created by a subsystem configuration registered with this extension point.
-
The extension markup is quite simple for this extension point,
+
The extension markup is quite simple for this extension point,
as it has only one element, <configuration>, with only a few simple attributes to supply:
id.
Unique id for the extension, as required for all extensions.
There is also a way to query a subsystem configuration
-object via its ID.
+object via its ID.
vendor.
-Your company name, shown in properties dialog for subsystems created by this subsystem configuration.
+Your company name, shown in properties dialog for subsystems created by this subsystem configuration.
icon.
-The icon displayed in the Remote Systems view for each subsystem created by this subsystem configuration.
+The icon displayed in the Remote Systems view for each subsystem created by this subsystem configuration.
iconlive.
-The icon used when the subsystem is physically connected to its remote system.
+The icon used when the subsystem is physically connected to its remote system.
name.
-The name displayed in the Remote Systems view for each subsystem created by this subsystem configuration.
+The name displayed in the Remote Systems view for each subsystem created by this subsystem configuration.
systemTypeIds.
A semi-colon separated list of system type IDs which this subsystem configuration supports. When a user creates a
connection, this configuration will only be asked to create a subsystem for connections to systems of these types. Wildcards are
-supported; in order to register against all system types, specify a single "*".
+supported; in order to register against all system types, specify a single "*".
serviceType. An optional semi-colon separated list of names and transports that can be used to match this service with remotelly advertised services through DNS-SD or any other supported service discovery protocol.
The name would usually be the keyword used by the IANA
-or by DNS SRV service types (RFC 2782).
+or by DNS SRV service types (RFC 2782).
category. A name used to categorize this subsystem's functionality. Used by the popupMenus
and propertyPages extension points to allow actions and property pages to be scoped to
-resources shown in subsystems of a particular category. Multiple subsystems can have the same category.
+resources shown in subsystems of a particular category. Multiple subsystems can have the same category.
class. A class implementing ISubSystemConfiguration
-interface, as described in the following programming details section.
+interface, as described in the following programming details section.
@@ -66,7 +67,7 @@ one system can manage the live connections of multiple subsystems in the same sy
If filters are supported
(the default), the first connection is made, and the remote resources are subsequently shown, when filters within the subsystem
are expanded, which results in a call to
-resolveFilterString
+resolveFilterString
in the subsystem object.
Furthermore, you will want to supply your own
registered for the remote objects, which the RSE views consult to get the labels, images, actions,
and property sheet values for the remote objects.
-Typically, you will supply actions by leveraging the user interface elements supplied by the RSE, such as base classes for messages, actions, dialogs, wizards, property pages and preference page editors. You will probably also supply a
+Typically, you will supply actions by leveraging the
+user interface elements supplied by the RSE, such as base classes for
+messages,
+actions,
+dialogs,
+wizards,
+property pages and
+preference page editors. You will probably also supply a
property page for your subsystem objects, via the Eclipse propertyPages extension point, and for your remote resource objects, via the RSE propertyPages extension point.
@@ -185,12 +186,12 @@ following summarizes the minimum set of classes you will be creating in order to
that implements the interface you designed in step 1. This will:
use your communications layer to return instances of your model objects in its internalResolveFilterString method.
The input to this is one or more strings such as you designed in step 5. It will return all remote resources matching the criteria captured in the input filter string.
You may also find the org.eclipse.rse.services.clientserver.NamePatternMatcher
class to be handy in comparing a generic pattern to a particular input. This class is in the runtime/clientserver.jar file,
- and has no eclipse-dependencies, so it can be used in your client subsystem code, or your server-side code.
+ and has no eclipse-dependencies, so it can be used in your client subsystem code, or your server-side code.
@@ -220,27 +221,23 @@ following summarizes the minimum set of classes you will be creating in order to
Create your own
filter string edit pane
- subclass that contains your own GUI prompts as desired.
+ subclass that contains your own GUI prompts as desired.