3.5 Managing your model

< Day Day Up >

Now that the editor base is built, you probably need to start reflecting your model. In this section we provide an overview of things to consider and describe some important issues related to handling models with our editor.

3.5.1 Reflecting a model

First we have to think about the architecture of our EditParts. The easiest way is usually to build the EditParts according to our model, but sometimes you may like another kind of representation of the model.

Whether you want a simple one-to-one representation or not, you need to have one main EditPart. This main EditPart is also called content EditPart and serves as the main entry point for your representation. It is important to understand this because each EditPartViewer can only have one content EditPart.

A content EditPart has nothing to do with a RootEditPart, but it might be possible that a RootEditPart defines some restrictions on the figure of the content EditPart (for example ScalableFreeformRootEditPart).

The figure of a content EditPart serves as the background figure of your graphical editor. Children can only be placed inside a figure.

Graphical model properties

A graphical editor presents your model in a graphical way. It is quite common for editors to allow users to lay out things the way they like. We have to think about this and decide which kind of support we will provide for layout.

The Graphical Editing Framework can use any Draw2D layout manager that is available. Some layouts requires the use of constraints (for example, location and size). These constraints belongs to a certain graphical representation of a model element. You have to decide if these constraints are persistent or not. If they are persistent, you have to find a location where you can store the constraint information.

The best way to do this depends on your preference and what fits best with your model. Mostly it is possible to store constraints together with the model element, either as a model property or as some kind of element annotation. If you do not like doing this, it is also possible to store them separately from your model.

3.5.2 Communication

If a model element is changed somehow or somewhere; a new issue arises - we have to ensure that all graphical representations of the model are updated accordingly. This requires communication between the model and the controller, which represents it.

It is not acceptable practice for your model to know about its controller, but a model can call attention to itself and to the change which has affected it.

It is up to you how you want to implement this, but a common way is to create some kind of event object, which is fired every time a change is done in the model. Then every controller can register with the model element itself or with an event manager and listen for such events.

As already mentioned in 3.3.2, "EditParts" on page 103, this is done best in EditPart#activate and EditPart#deactivate. When an EditPart receives an event for its model element, it has to decide whether it was a simple property change that only affects the figure (UI representation) or a structural change. In the first case, you would simply call EditPart#refreshVisual; and in the second case, you need to call EditPart#refreshChildren.

There are some dependencies that must be considered in event based communication for EditParts; for example, when connections are reconnected to another EditPart, both the old and the new EditParts need to be refreshed. You need to work out which parts need to be refreshed, but this is logically quite easy. For example, if a connection is reconnected to a new element, then elements affected by this change should also fire events in this case.

3.5.3 Creating EditParts

As mentioned in 3.3.2, "EditParts" on page 103, creating EditParts is best done through a factory. The EditPartFactory interface is simple to implement. It has only one method. In that method, you need to create an EditPart for a given model element in a specified context. The context might be useful if you consider a different UI representation than your model actually shows. Of course it is also necessary that you associate the specified model element with the created EditPart before you return the new EditPart.

You may consider building a map between the created EditParts and the model elements, but we do not recommend this. The EditPartViewer maintains an EditPart registry. EditParts register themselves to that registry. The default EditPart implementation already does this for you by using the model element as the key. Using the EditPart registry is a safe way to map between EditParts and the model elements.

One possible need for an EditPart registry is a domain based (global) listener model where there is only one listener, which does not belong to the model. This listener receives all the events from all model objects, and therefore it needs to find EditParts.

Note

If your model elements need to locate EditParts, you are probably not using the model-view-controller paradigm and should consider another solution.

< Day Day Up >