Multi-page form editors

UI Forms provide a basic support for multi-page editors you can build on.

You should start building a UI Forms multi-page editor by extending FormEditor:

public class SimpleFormEditor extends FormEditor {

	public SimpleFormEditor() {
	}

	protected FormToolkit createToolkit(Display display) {
		// Create a toolkit that shares colors between editors.
		return new FormToolkit(ExamplesPlugin.getDefault().getFormColors(
				display));
	}

	protected void addPages() {
		try {
		addPage(new FreeFormPage(this));
		addPage(new SecondPage(this));
		addPage(new ThirdPage(this));
		addPage(new MasterDetailsPage(this));
		addPage(new PageWithSubPages(this));
		}
		catch (PartInitException e) {
			//
		}
	}

	public void doSave(IProgressMonitor monitor) {
	}

	public void doSaveAs() {
	}

	public boolean isSaveAsAllowed() {
		return false;
	}

A very simple way to get started is to create pages and add them as above. Each page need to implement FormPage and override createFormContent(IManagedForm managedForm) method. Obviously there is a managed form already created in the page, and you should create contents in the enclosed form, and also register any form part that needs to be part of the managed life cycle.

In addition to form pages, you can add one or more text editors as a raw source alternative to the GUI pages. For this, you should call 'addPage(IEditorPart, IEditorInput input)' method in the superclass.

Recommended practices for Eclipse Forms multi-page editors

There are many ways you can go about writing a form-based multi-page editor. It mostly depends on the type of content you are editing and proficiency of your users. There are two ways you can approach it:

1. If the typical users are using the editor infrequently, raw source is hard to edit by hand or complex, your users are not very technical etc., you should make COMPLETE pages that are fully capable of editing every aspect of the content without the need to turn to the raw source. In this approach, source page is there only for occasional validation, rather than for regular work. In that respect, you can get away with a basic text editor. PDE extension point schema editor falls into this group.

2. If your users are more technical, have no problem editing the file by hand but would appreciate some help from time to time, consider providing a mixed experience - make a good source editor with all the add-ons like incremental outline, context assist, syntax highlighting etc. In turn, add complex value-add functionality in the form pages that are hard to achieve from source. We have learned from experience that it is very hard to convince seasoned users to switch from source editing if the value-add is marginal or debatable. However, functionality that was only available in GUI pages and was very high-quality was used readily.

Creating a high quality multi-page editor with mixed GUI and source pages has its challenges. Accepting that users will switch pages frequently requires a good model of the underlying content. The model should be directly tied to the underlying document(s) so that it is in sync both when users type in the text directly and when they change it structurally through the GUI pages (don't forget the indirect changes caused by other workbench actions while the editor is still up).