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.