From 98dcb78de011fc758a1420acacb326475a85aab0 Mon Sep 17 00:00:00 2001 From: Martin Oberhuber < martin.oberhuber@windriver.com> Date: Thu, 20 Jul 2006 13:15:28 +0000 Subject: [PATCH] Fix links into ../reference/api/org/eclipse/.. --- .../guide/Artifacts.html | 38 +- .../org.eclipse.rse.doc.isv/guide/Model.html | 32 +- .../guide/api/actions/uiActionsAPI.html | 32 +- .../guide/api/dialogs/uiDialogsAPI.html | 96 ++-- .../guide/api/logger/uiLoggerAPI.html | 2 +- .../guide/api/massagers/uiMassagersAPI.html | 14 +- .../guide/api/messages/uiMessageAPI.html | 56 +- .../guide/api/modelAPI.html | 8 +- .../guide/api/plugin/uiPluginAPI.html | 66 +-- .../api/preferences/uiPreferencesAPI.html | 10 +- .../guide/api/properties/uiPropertiesAPI.html | 12 +- .../guide/api/resourceAPI.html | 12 +- .../guide/api/uiAPI.html | 4 +- .../guide/api/validators/uiValidatorsAPI.html | 84 +-- .../guide/api/widgets/uiWidgetsAPI.html | 18 +- .../guide/api/wizards/uiWizardsAPI.html | 44 +- .../guide/plugin/other.html | 16 +- .../guide/plugin/popup.html | 8 +- .../guide/plugin/propertypage.html | 4 +- .../guide/plugin/subsystem.html | 96 ++-- .../guide/tutorial/subsystem.html | 540 +++++++++--------- 21 files changed, 596 insertions(+), 596 deletions(-) diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/Artifacts.html b/rse/doc/org.eclipse.rse.doc.isv/guide/Artifacts.html index 2ba4030d7df..325de4c521a 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/Artifacts.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/Artifacts.html @@ -120,13 +120,13 @@ subsystems share. System objects are described next.

Systems and System Managers

While not seen by the user, subsystem objects are required to return a connectorservice object via the -getConnectorService() method. -A connectorService object is an object implementing the IConnectorService interface. +getConnectorService() method. +A connectorService object is an object implementing the IConnectorService interface. A connectorService object manages the live host to the remote system, and supports lifecycle methods for that host such as -connect, -disconnect, and -isConnected. +connect, +disconnect, and +isConnected. The communication layer for that host is entirely the programmer's responsibility, and might use sockets, JDBC, HTTP or SOAP. It is up the provider of the subsystem factory to author their own communication layer; the framework only dictates the handful of methods in IConnectorService, that the RSE UI depends upon. The framework supplies a base @@ -134,7 +134,7 @@ system class that is easily extended.

It may be the case that multiple subsystems, each from a different subsystem configuration, share the same live host for a given host object. To enable this, the framework supplies a base -connector service manager class +connector service manager class that can be used to manage a single shared connector service object across multiple subsystems. It uses a hashtable to store and return the connector service objects, keyed by a subsystem interface that all subsystems sharing the same connector service object are to implement. The subclass of the base connector service manager class supplies that interface. Further, the subclass @@ -147,8 +147,8 @@ the RSE-supplied subsystems. You might do this if the subsystem configuration us accessing remote objects, in which case there is no need for a unique communication layer. By sharing the same connector service object, it prevents the user from being prompted to signon multiple times. To do this, simply access any RSE-supplied subsystem for a given host, and ask for its -connector service manager -in your own subsystem's getConnectorServiceManager method. +connector service manager +in your own subsystem's getConnectorServiceManager method.

Filters

@@ -156,7 +156,7 @@ in your own subsystem's ISystemFilter +A filter is simply a ISystemFilter object containing a name and a collection of filter strings. Filter strings are just strings, which the subsystem is required to interpret. When a user expands a filter, the owning subsystem is asked to resolve the filter strings within the filter. The subsystem typically interprets each filter string as some form of @@ -175,12 +175,12 @@ It is possible to author a subsystem that does not support filters, if this is d Subsystems do not actually "own" filters. Since each host has unique subsystems, if each subsystem owned its own filters then filters could not be shared across Hosts, which is sometimes desirable. Instead, filters are actually contained within filter pools. Filter pools are simply -ISystemFilterPool +ISystemFilterPool objects which have a name and a collection of filters. Filter pools are owned by subsystem configurations, per profile. That is, each subsystem configuration will contain filter pools scoped by profile. Each such configuration plus profile grouping is known internally as a -filter pool manager. -Subsystems contain references +filter pool manager. +Subsystems contain references to filter pools. By default, each subsystem configuration automatically creates one filter pool for each profile, named the "xxx Filter Pool", where "xxx" is the name of the profile. Subsystems contain references to filter pools, so that as the filters in the pool are created, changed, deleted or re-ordered, those changes are automatically @@ -209,7 +209,7 @@ reference it.

User Actions and Named Types

If the subsystem configuration returns true to the -supportsUserDefinedActions +supportsUserDefinedActions method, users can create their own actions that appear in the pop-up menu for remote objects, using the Work With User Actions action and dialog. User actions use substitution variables that are resolved at @@ -228,7 +228,7 @@ This is done using the Work With Named Types dialog.

User actions are contained by each subsystem factory, scoped by profile. You can programmatically access them by calling -getSubSystemActions +getSubSystemActions in a subsystem configuration object. They are scoped to the configuration, not the subsystem, so the same list of actions is available for every host. The User Actions cascading menu for remote objects lists all the actions defined for all active profiles, whose file type scoping criteria matches the @@ -247,7 +247,7 @@ It is assumed there will be fewer of these, and they are not likely to be differ

Compile Commands

If the subsystem configuration returns true to the -supportsCompileActions +supportsCompileActions method, users will see a Compile action in the pop-up menu for compilable source files. Clearly, this support usually only makes sense for subsystems that list remote source files. Whether a selected file is compilable or not is decided by the subsystem factory. It @@ -257,7 +257,7 @@ class for this. The compile manager is also responsible for pre-supplying defaul

The framework also supplies a Work With Compile Commands action and dialog, by which users can create their own compile commands, -per source type. Compile commands internally are SystemCompileCommand objects. +per source type. Compile commands internally are SystemCompileCommand objects. These compile commands are stored per subsystem configuration, such that they are usable across all Hosts. They are also scoped by profile, and the cascading compile action will list all compile commands from all active profiles, for the selected file's source type. This scoping by profile, as with user actions, enables team support such that @@ -277,11 +277,11 @@ be exported and imported.

System Registry

The programmatic front door to all the artifacts in the RSE is the System Registry, which is an object implementing -ISystemRegistry. +ISystemRegistry. This is a singleton object that you can access by calling the static method -getSystemRegistry() in the -SystemStartHere +getSystemRegistry() in the +SystemStartHere class in the org.eclipse.rse.ui plugin.

diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/Model.html b/rse/doc/org.eclipse.rse.doc.isv/guide/Model.html index 0246777b463..dba1d5cea69 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/Model.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/Model.html @@ -14,39 +14,39 @@

The underlying containment model for the RSE artifacts is shown here.

diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/api/actions/uiActionsAPI.html b/rse/doc/org.eclipse.rse.doc.isv/guide/api/actions/uiActionsAPI.html index 2ba323f7cfb..841132b6640 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/api/actions/uiActionsAPI.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/api/actions/uiActionsAPI.html @@ -31,7 +31,7 @@ help simplify the creation of action classes, especially when used together with

RSE-Supplied Base Classes for Actions

Here are the primary base classes the RSE supplies for actions, all of which are found in the -package +package in the plugin org.eclipse.rse.ui:

@@ -40,36 +40,36 @@ in the plugin org.eclipse.rse.ui:

- + - - + + automatically call the method getSubMenu when populating the initial popup menu, but your own views will need to do this. - - + + SystemPromptDialog class. To use this class, subclass it and override the methods - - + + @@ -79,9 +79,9 @@ in the plugin org.eclipse.rse.ui:

You may find some of the actions supplied by the RSE to be immediately re-usable in your own code, saving some development and test effort. All these actions can be found in package -org.eclipse.rse.ui.actions. +org.eclipse.rse.ui.actions. Further, you can find many useful actions related to the selection of remote files or folders, in package -org.eclipse.rse.files.ui.actions. +org.eclipse.rse.files.ui.actions.


diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/api/dialogs/uiDialogsAPI.html b/rse/doc/org.eclipse.rse.doc.isv/guide/api/dialogs/uiDialogsAPI.html index ccf955b92c4..208c02bbf17 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/api/dialogs/uiDialogsAPI.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/api/dialogs/uiDialogsAPI.html @@ -22,9 +22,9 @@ modal, meaning the rest of the application (in this case eclipse) is disabled while the dialog is showing. Eclipse supplies a raw dialog class in SWT, as well as more robust dialog class in JFace. The RSE supplies its own class, -SystemPromptDialog +SystemPromptDialog in package -org.eclipse.rse.ui.dialogs +org.eclipse.rse.ui.dialogs , that extends the JFace dialog class and adds to it the following capabilities inherited by all classes which extend it:

@@ -40,39 +40,39 @@ effort if your user interface is translated as the assignment of unique mnemonic
  • Built-in support for a number of typical push buttons at the bottom of the dialog: OK, Cancel, Browse, Test, Add and Details. You control via setters which buttons to show, and you can affect their label and tooltip text, although the default labels and tips are already translated for you. To program what happens when pressed, override the appropriate -processXXX() method, such as processOK(). By default, you get OK and Cancel buttons. +processXXX() method, such as processOK(). By default, you get OK and Cancel buttons.
  • Support for an optional built-in progress monitor at the bottom of the dialog, just like what eclipse offers for wizards. -
  • Support of a simple wasCancelled() method to easily test if the dialog was cancelled or not. +
  • Support of a simple wasCancelled() method to easily test if the dialog was cancelled or not.
  • Support for methods to set an input object, and retrieving an output object, making it easy to pass in data and get back data. Your calling code sets the input object, your subclass code sets the output object (typically in -its processOK() method) and your calling code gets the output object, -if wasCancelled() returns false. -
  • Support of a setPageComplete(boolean) method, consistent with wizard pages, to enable/disable the OK button. +its processOK() method) and your calling code gets the output object, +if wasCancelled() returns false. +
  • Support of a setPageComplete(boolean) method, consistent with wizard pages, to enable/disable the OK button. This is typically called by your keystroke and button validators. That is, if an error is detected as input is entered, a message is issued to the message line and the OK button is disabled. -
  • Support of a simple setHelp(String helpId) method to set the dialog's popup help. +
  • Support of a simple setHelp(String helpId) method to set the dialog's popup help.
  • A simple way to toggle the cursor between busy and normal, using -setBusyCursor(boolean) -
  • Helper methods for adding filler lines -and separator lines. +setBusyCursor(boolean) +
  • Helper methods for adding filler lines +and separator lines.

    To create your own dialog:

      -
    1. Subclass SystemPromptDialog, picking the appropriate constructor, the simplest +
    2. Subclass SystemPromptDialog, picking the appropriate constructor, the simplest of which simply requires the shell of the parent window and the title string for this dialog.
    3. If buttons beyond OK and Cancel are desired, in your own constructor call the appropriate setShowXXXButton(true) methods to enable these buttons, and override the appropriate processXXX() methods to process these buttons when pressed by the user. -
    4. If a progress monitor is desired, in your own constructor call setNeedsProgressMonitor(true). Later, to run -a long-running operation that displays the progress monitor, use getProgressMonitor(). -
    5. Override the createInner(Composite) method to populate the client area of the dialog with SWT widgets. Typically +
    6. If a progress monitor is desired, in your own constructor call setNeedsProgressMonitor(true). Later, to run +a long-running operation that displays the progress monitor, use getProgressMonitor(). +
    7. Override the createInner(Composite) method to populate the client area of the dialog with SWT widgets. Typically you create your composite with a GridLayout layout, populate it, and return it. To ease this programming burden, use the many -static helper methods in SystemWidgetHelpers. -
    8. Override the getInitialFocusControl() method to supply the control to get initial focus when the dialog is displayed. -
    9. Override the processOK() method to supply the processing for when OK is pressed. You typically first validate +static helper methods in SystemWidgetHelpers. +
    10. Override the getInitialFocusControl() method to supply the control to get initial focus when the dialog is displayed. +
    11. Override the processOK() method to supply the processing for when OK is pressed. You typically first validate the user input, and then return true if there are no errors found.
    12. To allow the caller to get user-entered information out of the dialog, either supply getter methods, -or call setOuputObject(Object) -in your processOK logic so that your caller can code getOutputObject(). +or call setOuputObject(Object) +in your processOK logic so that your caller can code getOutputObject().

    One of the more difficult efforts in building a dialog with multiple entry fields, is the code to do the validation of those entry fields. A common strategy is to add modify listeners to the entry fields, and for each one validate the data as it typed. If the validation fails, a message is issued. If the validation succeeds, then the other fields on the dialog are validated. At the end of the validation, the OK button is enabled or disabled depending on the error message status, and whether the required information has been supplied. The RSE can help with this effort, somewhat, through the use of re-usable validators for various types of input.
    @@ -81,11 +81,11 @@ Follow this link for an example of a fully-forme error checking.

    Typically, after creating your dialog, you will create an action to invoke it. The RSE can help with this too, via the -supplied SystemBaseDialogAction base class. +supplied SystemBaseDialogAction base class.

    Dialogs Pre-Supplied by RSE

    You may find some of the dialogs supplied by the RSE to be immediately re-usable in your own code, saving some -development and test effort. All these dialogs are in package org.eclipse.rse.ui.dialogs: +development and test effort. All these dialogs are in package org.eclipse.rse.ui.dialogs:

    @@ -98,51 +98,51 @@ development and test effort. All these dialogs are in package SystemRenameDialog +
    • - + - + - + - + - + - + - + - + @@ -152,11 +152,11 @@ development and test effort. All these dialogs are in package org.eclipse.rse.ui.actions package. +The action classes are all in org.eclipse.rse.ui.actions package.

    In addition to these universal dialogs, there are dialogs specific to the Files subsystem supplied by IBM. These enable selection -of remote files or folders. They can be found in the +of remote files or folders. They can be found in the org.eclipse.rse.files.ui.dialogs package.

    Description
    SystemBaseActionSystemBaseAction This is the base action class for the other classes, and is only used directly for actions that do not result in a dialog or wizard being presented to the user. It extends the JFace Action class, adding to it support for properties such as the current shell and viewer and selection, as well as overridable methods for easily enabling/disabling the action based on the selection, and a method for setting the context help for the action. There are many other useful methods, such - as allowOnMultipleSelection(boolean) - and setContextMenuGroup(String), to + as allowOnMultipleSelection(boolean) + and setContextMenuGroup(String), to simplify when the action is enabled and where it appears in a popup menu.
    SystemBaseSubMenuActionThis base action class extends SystemBaseAction, and is used as the parent class when + SystemBaseSubMenuActionThis base action class extends SystemBaseAction, and is used as the parent class when for popup menu actions that are to cascade. A cascading menu is itself another menu, really, containing actions just like the primary menu does. So, to create a cascading menu action, you simply subclass this class and override the method - populateSubMenu, where + populateSubMenu, where you add all the actions to show in this cascading menu. And yes, one or more of those can themselves be cascading. The RSE views will - automatically call the method getSubMenu when populating the initial popup menu, but your own views will need to do this.
    SystemBaseDialogActionThis base action class extends SystemBaseAction, and is used when the action presents the + SystemBaseDialogActionThis base action class extends SystemBaseAction, and is used when the action presents the user with a dialog, preferably a dialog that extends the RSE - SystemPromptDialog class. To use this class, subclass it and override the methods
    SystemBaseWizardActionThis base action class extends SystemBaseAction, and is used when the action presents the - user with a wizard, preferably a wizard that extends the RSE AbstractSystemWizard class.SystemBaseWizardActionThis base action class extends SystemBaseAction, and is used when the action presents the + user with a wizard, preferably a wizard that extends the RSE AbstractSystemWizard class.
    SystemRenameDialog Rename multiple items. Provides a table listing the old names and new names, which are editable. If your input objects - do not adapt to ISystemViewElementAdapter - or ISystemRemoteElementAdapter, - you should call setNameValidator to specify a validator that ensures the new name is correct, and your + do not adapt to ISystemViewElementAdapter + or ISystemRemoteElementAdapter, + you should call setNameValidator to specify a validator that ensures the new name is correct, and your input objects should also either be IResource objects or implement - ISystemTypedObject. + ISystemTypedObject. Sample imageSystemCommonRenameActionSystemCommonRenameAction
    SystemRenameSingleDialogSystemRenameSingleDialog Rename a single item. Provides a simple entry field for the new name. If your input object - does not adapt to ISystemViewElementAdapter or - ISystemRemoteElementAdapter, - you should call setNameValidator to specify a validator that ensures the new name is correct, and your - input object should also either be an IResource object or implement ISystemTypedObject. + does not adapt to ISystemViewElementAdapter or + ISystemRemoteElementAdapter, + you should call setNameValidator to specify a validator that ensures the new name is correct, and your + input object should also either be an IResource object or implement ISystemTypedObject. Sample imageSystemCommonRenameActionSystemCommonRenameAction
    SystemDeleteDialogSystemDeleteDialog Confirm delete of one or more items. Provides a table listing the names of input objects. If your input objects - do not adapt to ISystemViewElementAdapter or - ISystemRemoteElementAdapter, - your input objects should either be IResource objects or implement ISystemTypedObject. + do not adapt to ISystemViewElementAdapter or + ISystemRemoteElementAdapter, + your input objects should either be IResource objects or implement ISystemTypedObject. Sample imageSystemCommonDeleteActionSystemCommonDeleteAction
    SystemSelectFileTypesDialogSystemSelectFileTypesDialog Presents a dialog listing all the file types defined in the eclipse File Associations preferences page, and allows the user to select one or more of these types, or enter additional types not defined in eclipse. Sample imageSystemSelectFileTypesActionSystemSelectFileTypesAction
    SystemSimpleSelectDialogSystemSimpleSelectDialog Eclipse has a CheckboxTreeViewer that is designed to allow the user to select multiple items from a hierarchical model. This is a nice viewer, but very difficult to program to, as you have to handle reflecting the state of the selected children for each parent node yourself. This dialog makes that trivial. The trick is to create wrappers of your model objects using - SystemSimpleContentElement, maintaining the parent/child hierarchy, and pass the root element to the dialog. The rest is + SystemSimpleContentElement, maintaining the parent/child hierarchy, and pass the root element to the dialog. The rest is done for you, and the result is the selected state set for those elements selected by the user. Note this can also be used as a simple flat list checkbox selection dialog, just by passing a non-visible root with a flat list of children. Sample image
    @@ -168,14 +168,14 @@ org.eclipse.rse.files.ui.dialogs package. - + - +
    Action
    SystemSelectRemoteFileOrFolderDialogSystemSelectRemoteFileOrFolderDialog Allows users to select a remote file, or folder (configurable) using a dialog similar to what is used in Eclipse for local file or folder selection. Can be configured to allow user to select from any existing connection, or to be scoped to a particular connection, or even a particular folder in a particular connection. Sample imageSystemSelectRemoteFileAction or - SystemSelectRemoteFolderActionSystemSelectRemoteFileAction or + SystemSelectRemoteFolderAction
    diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/api/logger/uiLoggerAPI.html b/rse/doc/org.eclipse.rse.doc.isv/guide/api/logger/uiLoggerAPI.html index a46087afbc3..21cf04b63a1 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/api/logger/uiLoggerAPI.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/api/logger/uiLoggerAPI.html @@ -17,7 +17,7 @@ or want to use the common RSE log file.

    Using Your Own Log File

    The log file support is encapsulated in a separate plugin, org.eclipse.rse.logging, which -defines the primary org.eclipse.rse.logging.Logger class that manages the log file. +defines the primary org.eclipse.rse.logging.Logger class that manages the log file. This log file support offers the ability to log the following types of log messages: