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:

@@ -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:
  • Creating a subclass of SubSystemConfiguration.
    • @@ -220,27 +221,23 @@ following summarizes the minimum set of classes you will be creating in order to
    1. 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.
    2. Create your own new-filter wizard action subclass, and configure it to use your own edit pane subclass by overriding configureNewFilterWizard and in it calling setFilterStringEditPane - on the given wizard. + on the given wizard.
    3. Create your own change-filter action subclass, and configure it to use your own edit pane subclass by overriding configureFilterDialog and in it calling setFilterStringEditPane - on the given dialog. -
    4. Override the getNewFilterPoolFilterAction(SystemFilterPool, Shell) - method in your subsystem configuration, to return an instance of your new-filter action. + on the given dialog.
      5. +
    5. Override the getNewFilterPoolFilterAction(SystemFilterPool, Shell) + method in your subsystem configuration, to configure your new-filter action. You can actually avoid creating an action subclass if you choose, by calling the configuration methods - in the RSE-supplied new-filter action class. -
    6. Override the getChangeFilterAction(SystemFilter, Shell) - method in your subsystem configuration, to return an instance of your change-filter action. - You can actually avoid creating an action subclass if you choose, by calling the configuration methods - in the RSE-supplied change-filter action class. + in the RSE-supplied new-filter action class.