Although the implementation of a workbench editor will be specific to your plug-in and the
content that you want to edit, the workbench provides a general structure for building an
editor. The following concepts apply to all workbench editors.
Editor parts and their inputs
An editor must implement
and is often built by extending the
class. An editor implements its user interface in the createPartControl
method. This method is used to assemble the SWT widgets or JFace viewers
that present the editor contents.
An editor input is a description of something to be edited. You can think of
an editor input as a file name, though it is more general.
IEditorInput defines the protocol for an editor input, including the name of the input and the image that should be used to represent it in
the labels at the top of the editor.
Three generic editor inputs are provided in the platform.
IFileEditorInput represents an input
that is a file in the file system, and
IURIEditorInput represents an input based on a URI.
IStorageEditorInput represents an input
that is a stream of bytes. These bytes may come from sources other than the file system.
Resetting the editor input
If your editor can support the replacement of the
editor's input object on the fly, you should implement
Implementing this interface allows the workbench to "recycle" your
editor. Workbench user preferences allow the user to dictate that editors
should be reused after a certain number of them are open.
Navigating the editor input
If you want to implement a navigation history in your editor, you should
This provides a mechanism for the workbench to request a current navigation
as needed to keep a navigation history. The workbench handles the
mechanics of the navigation user interface. Your
will be notified when it needs to restore the editor to the location that it represents.
The rest of your editor's implementation depends on the content that you are
trying to present. We'll look next at the most common type of editor - the