Editors
We have seen how plug-ins can contribute an editor to the workbench, but we
haven't yet looked at the implementation of an editor.
There is no "typical" implementation pattern for an editor, because editors usually provide application-specific semantics.
A tool that edits and manages a particular content type will
provide customized behavior for manipulating the data represented by the resource.
Editors can come in all shapes and sizes. If a plug-in's editor is text-based, then the editor can either use the existing default text editor, or create a customized text editor
by using the facilities provided in the platform. The latter approach is used by the
Java example editor.
If a plug-in's editor is not text based, then a custom editor must be implemented by the plug-in. There are several approaches for building
custom editors, all of which depend on the look and behavior of the editor.
-
Form-based editors can layout controls in a fashion similar to a dialog or wizard.
The Plug-in Development Environment (PDE) uses this approach in building its
manifest editors.
-
Graphics intensive editors can be written using SWT level code. For
example, an editor could create its own SWT window for displaying the
information, or it could use a custom SWT control that is optimized for the
application.
-
List-oriented editors can use JFace list, tree, and table viewers to manipulate
their data.
Once the implementation model for the editor has been determined, implementing the editor is much like programming a stand-alone JFace or SWT application.
Platform extensions are used to add actions, preferences, and wizards needed to
support the editor. But the internals of the editor are largely dependent
on your application design principles and internal model.
