GEF source code analysis (3) Tree Structure of GEF ___ model/editpart/figure

GEF source code analysis (3) Tree Structure of GEF ___ model/editpart/figure

Tree object model creation process
 

If you want to create editable2dGraphicsProgram, The basic requirements must be as follows:

• On the one hand, we haveModelObject group, which includes some businesses andUIDisplay data;
• On the other hand, we have a view that will contain a set of visualization objects that define how to depict on the screen;
• users are able to modify graphical views with the mouse and keyboard. This needs to be established in some way within the Program UI object and Model association method, through the association between the two, when the view changes, Model changed while Model there may also be a change in the business logic that needs to be notified to the view.

In this way, we provide users with a graphical interaction method to modify the business.ModelPrograms with this capability can be called editable.2dA Graphical Editor ).

 

 

As discussed in the previous articleGEFThe framework forms three corresponding tree object models.

To meet the above requirements,GEFPassEditpartFor exampleViewAndModel.

Then the problem arises:

These tree object models How? When? Create

What is particularly difficult is how to simplify the methods inEditpartAre they associated?

 

 

GEFThe following answers are provided:

 

We can see that inGEFYesEditpartfactoryBased on the existingModelTo create and set differentEditpart.

EditpartfactoryThe interface is as follows:

Editpart createeditpart (editpart context, object model );

Where Model Yes Object Type, so we can see in GEF Pair Model There are no too many constraints, Context Is to be created Editpart Associated Editpart For example Editpart Of Parent .

This way GEF It is very easy to use the Sequence Chart (it is not easy to learn ). ) , According Model The object framework has two other Editparts And Figures Tree system.[LINK]See the following figure. Sequence Chart .

The important methods in the creation process are as follows:

ClassShapeSeditor

Protected voidConfiguregraphicalviewer (){..}

Protected voidInitializegraphicalviewer(){..}

 

ClassShapeSeditpartfactory

Public editpart createeditpart (editpart context, object modelelement ){

// Get editpart for Model Element

Editpart part = getpartforelement (modelelement );

// Store model element in editpart

Part. setmodel (modelelement );

Return part;

}

 

/**

* Maps an object to an editpart.

* @ Throws runtimeexception if no match was found (programming error)

*/

Private editpart getpartforelement (Object modelelement ){

//Based on differentModelGenerate differentEditpart

If (modelelement instanceof shapesdigoal ){

Return new diagrameditpart ();

}

If (modelelement instanceof shape ){

Return new shapeeditpart ();

}

If (modelelement instanceof connection ){

Return new connectioneditpart ();

}

Throw new runtimeexception (

"Can't create part for model element :"

+ (Modelelement! = NULL )? Modelelement. getclass (). getname (): "null "));

}

 

 

Class shapeeditpart

Public void setmodel (Object Model ){

If (GetModel () = Model)

Return;

This. Model = model;

}

 

Protected ifigure createfigure (){

Ifigure F = createfigureformodel ();

F. setopaque (true); // non-transparent figure

F. setbackgroundcolor (colorconstants. Green );

Return F;

}

 

/**

* Return a ifigure depending on the instance of the current model element.

* This allows this editpart to be used for both sublasses of shape.

*/

Private ifigure createfigureformodel (){

//Based on differentModelCreate differentFigure

If (GetModel () instanceof ellipticalshape ){

Return new ellipse ();

} Else if (GetModel () instanceof rectangularshape ){

Return new rectanglefigure ();

} Else {

// If shapes gets extended the conditions above must be updated

Throw new illegalargumentexception ();

}

}

 

Now, we have a tree-like MVC framework, but some problems remain unsolved:
For example, a triangle image editpart already exists and we want to reuse it. But we also need to add (or delete) the adjustable border feature. How can we ensure that a new editpart does not need to be created, or are there countless sub-editpart classes when the functions are combined?
During interface operations, we want to face border adjustment events, or edit text events, rather than the original mouse and keyboard events?
I hope that the editpart can automatically notify the event to the corresponding parent and sub-editpart, and respond to the event in the correct order?
How does the framework automatically complete the Undo and redo functions?
.....