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:
-
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.
-
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, function 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).