7.4 Implementing the multi-page editor

< Day Day Up >

When implementing a multi-page editor, there are several issues which have to be considered before and during development. This section gives you an introduction to a possible multi-page editor implementation. It also discusses some issues encountered during our development of the sample application.

Note

The source code of our sample application is available along with this book. See Appendix A, "Additional material" on page 225 for details on obtaining the sample code. We suggest that you study the code for implementation details. We tried to document it as often as possible. Because of that, we are not going to reproduce a lot of example code within this section. Instead, we give you an overview of the implementation and explain what and why implementation decisions were made.

Our multi-page editor consists of only two pages One page is for editing a whole workflow and the second page is for editing compound tasks of the same workflow. This provides an alternative way of editing compound tasks because in-place editing might not be suitable in all situations.

7.4.1 Getting started

First we start creating our multi-page editor by extending org.eclipse.ui.parts.MultiPageEditorPart. Thus, our main editor class is the class WorkflowEditor, which has to be registered as an Eclipse extension in the plugin.xml in the regular way.

The MultiPageEditorPart uses regular IEditorPart implementations or simple controls as editor pages. Because we expected that there will be some code that is shared between our editor pages, we created an abstract editor page AbstractEditorPage.

Note

In general, we reuse as much code as possible from the concepts described in Chapter 3, "Introduction to GEF" on page 87.

7.4.2 Sharing an EditDomain

One of the most important questions is what to share within your pages. However you decide to do this, you will have to consider some issues.

We decided not to share a single EditDomain within our editor pages. Our reasons were clear, because our editor would only have two pages. The functionality of each page might be similar, but the concept of each page is different.

On one page you should be able to edit the workflow, and on the second page you should edit the content of compound tasks. We thought that changes on one page should not affect the other page except for updating the UI. Thus, we wanted to have completely different undo/redo stacks for each page.

If you want all your pages to be using the same undo/redo stack (CommandStack), you will have to share the EditDomain between your pages.

Because of some current limitations in GEF, you have to think about solutions for the following issues:

If you share an EditDomain within several pages, you have to remember that an EditDomain can have several EditPartViewers but only one palette.
Thus, you might consider a concept of sharing one palette or attaching a new palette with every page switch.

7.4.3 The editor's dirty state

You have two options for resolving this for a multi-page editor. Either you delegate this to every page or you implement this only once for the whole editor.

We decided to implement this directly into the multi-page editor because we think it might be less expensive to calculate this once for all pages rather than letting each page calculate this itself and asking each page.

The concept is basically the same as we would have used for a simple editor. The editor listens for CommandStack changes and updates its dirty state according to the state of the CommandStack.

Our WorkflowEditor provides a MultiPageCommandStackListener, which is capable of listening to multiple CommandStacks. All CommandStacks that need to be observed can be registered to it. We do this at the same time we create our pages.

7.4.4 Actions

Our multi-page editor provides one ActionRegistry for the whole editor. Thus, all actions are available on all pages. We don't need to have different actions for different pages. Again the concept is similar to a single editor. Actions are registered to an ActionRegistry.

The ActionBarContributor

The GEF ActionBarContributor is not able to provide support for tracking page changes in a multi-page editor. If you need this, you can either implement the functionality from org.eclipse.ui.part.MultiPageEditorActionBarContributor or inherit from this class. But if you inherit from this class, you don't have the action handling support provided by the GEF ActionBarContributor.

7.4.5 Support for the properties view

The base concept is similar to a single editor. Our multi-page editor uses the undoable property sheet root entry provided by GEF. But this is only capable of committing to one CommandStack. If you share only one EditDomain within all pages, there is no special work necessary and you can stop here.

Due to internal caching in Eclipse, it is not possible to have a separate property sheet page for every single page. There can be only one for the whole editor. But somehow the property sheet page needs to keep track of the active page to commit to the correct CommandStack.

We are handling this with a workaround. Our undoable property sheet page root entry gets a delegating CommandStack. The DelegatingCommandStack is a CommandStack that delegates work to a current CommandStack, which can be changed. Thus, we only need to update the DelegatingCommandStack when the current page changes, and this can be easily done from within our multi-page editor.

7.4.6 The outline view

We had a little bit more work to do for the outline view, but basically the concept is the same as seen before. The outline view is updated every time the page changes. Although it is strongly connected to our multi-page editor, we tried to keep the implementation as generic as possible to allow you to reuse it for your projects.

The implementation can be found in WorkflowEditorOutlinePage. It provides both a tree outline and an overview figure. You only need to call one method on each page change to reinitialize the outline view with a new content. This can be easily done from within our multi-page editor.

7.4.7 The palette

Each page has its own PaletteViewer. You can't share one PaletteViewer instance within several pages. It is possible to have only one PaletteViewer for the whole editor, but this must be implemented in the multi-page editor class because the SWT control needs to be created there.

However, having multiple PaletteViewers is no issue because you can share a single PaletteRoot between them, like we did. Our multi-page editor provides the same PaletteRoot for every page. If you would like to have different PaletteRoots for your pages, this is no problem either. You just have to implement it that way.

< Day Day Up >