Diagrams beyond Editors

Starting with Graphiti 0.10.0 it is possible to add diagrams to other UIs besides editors. Before that release there was no way to display a diagram outside of an editor. Prominent use cases are e.g. to place a diagram inside an Eclipse view or onto a popup. But it would also be possible to add a diagram into a any other SWT UI just as a composite.

Different from the editor use case where Graphiti brings everything that is needed to display and edit diagrams in an editor, clients have to define the UI part (e.g. the Eclipse view) by themselves. There are no base classes corresponding to DiagramEditor like DiagramView or DiagramPopup. This is because the usage varieties are much greater than with editors. But a large part of the functionality can be reused from the editor. This was enabled in the Graphiti framework by splitting the former GraphitiEditor class into two parts: one consisting of the new DiagramEditor class providing the functionality that is only needed for Eclipse editors and a new class DiagramBehavior that provides functionality that may be used independently from the editor. The latter is embedded both into the editor and into the new DiagramComposite class that users might embed into other kinds of UIs, like Eclipse views or popups. This architecture allows the Graphiti framework to provide the standard functionality of Graphiti diagrams within editors and views and clients to be flexible in respect to their view implementations.

There are some basic examples on how to use a diagram composite within an Eclipse view and a popup included in the SDK download. For details see the section on the composite example.

One important aspect to keep in mind is that the diagram composite always embeds a complete GEF diagram viewer instance (DiagramBehavior cares about embedding that). Since GEF diagram viewers are tightly coupled with editors, also the Graphiti diagram composite incorporates much of the functionality and the lifecycle requirements of an editor. Also since GEF uses standard Eclipse 3.x APIs it is not possible to embed such a diagram composite into an E4 part without using the 3.x compatibility layer. Using the compatibility layer, this is of course possible.

While DiagramComposites embed the complete functionality of a Graphiti diagram editor and enable the user to trigger all features that would also be available in an editor, it is up the the client implementing the view, popup or other integrating part to embed the functionality into the environment. Clients will have to care about things like:

• Should changes be allowed in the view? This could be disabled in the view implementation or by using a read-only DiagramTypeProvider (one that has a feature provider without any modifying features). Of course changes might also be possible.
• In case changes are allowed the save handling must be implemented by the client.
• Tool bars and menus in the main tool bar and menu need to be added and enabled. Associated keybindings need to be established.
• A way how to open the view needs to be implemented. An already existing view might be populated with a new diagram. Clients are in this case fully responsible for disposing old diagrams, their diagram type providers and all other used resources.
• ...

More examples on how to achieve things like described above will be added in future versions of Graphiti.

The DiagramBehavior instance used inside an editor and a view might be reused between the different viewing locations and can share client adaptations to the default behavior that clients can implement by replacing the various Default...Behavior objects. This possibility has been established for Graphiti editors in Graphiti 0.9.0 and has been taken over for diagram composites as well.