Software Development - Eclipse

An Eclipse Framework for Rapid Development of Rich-featured GEF Editors based on EMF Models - Long Version

The Graphical Editing Framework (GEF) ships with a painting and layout plug-in called Draw2D. Draw2D provides figures and layout managers which form the graphical layer of a GEF application. This article focuses only on the use of Draw2D to render a simple UML class diagram. While Draw2D can be used for standalone purposes, it is not an editing framework. Most applications will use the GEF plug-in as the editing layer.

As I had myself huge difficulties to fiddle with GEF for the needs of an Eclipse application, I decided to put together my knowledge on this subject HERE in order that others can benefit from it.

GEF's Workflow:

1. Editor accepts user operation and converts to a request which will be submitted to controller
2. Controller accepts the request which will be forwarded to the Edit Policy Manager
3. The Edit Policy Manager establishs command for request
4. Editor executes Command and modifies the Model
5. Controller monitors Model's change and notifies View to update
6. View refreshes display

Conditions for Model:

1. Model contains all data user wants to modify
2. Model cannot hold any reference to its View and it can not understand the rest of the editor
3. Model must notify its changes to Controller

Conditions for View:

1. View cannot hold any data which is not defined in Model.
2. View can not hold any reference to the Model
3. View does not reference Controller and does not participate in controller logic.

Advantages of GEF Structure:

Model is used to store data and the View is used to display data. The Controller is used to bind Model and View logic. Therefore, Model is concise and well-defined, and roles of the structure are clearly separated, and it facilitates design and implementation.

Event Notification

Model must implement a notification mechanism that the Controller listens to. In turn, the Controller will notify the View to update based on the Model's new state.

User interacts with the Graphical Editor and its role is to convert the Model to a graphical presentation. It also provides edit, graphical feedback, tool tips and other functions.

The event flow is as follows: mouse or key events are translated to requests and these requests are eventually executed in commands which in turn modifies the Model. The Model notifies the Controller and the controller updates the View.

This is the question I had, and I like the answer someone gave in this blog. The MVC defined originally indicated that the View had knowledge of the Model but GEF makes the View completely ignorant of the model. I personally like that better since it reduces dependency of the View on the Model and since the controller needs to know about both the Model and View why not have the controller update the View through a properties interface. Here is vainolo's response:

The wikipedia states a the start of the article on MVC that " MVC comes in different flavors (MVC overview). Sometimes the view can read the model directly and update itself, sometimes this is done by the controller.

Hope this clears things up for you. - Vainolo

Cocoa Version of MVC - notice the separation of View and Model as compared with the traditional MVC

I think this guy has the definition of MVC right. - JS

Sounds like there is disagreement and misunderstanding :) I don't claim to offer the "correct" answer, but I will define how *I* have been applying MVC to good effect lately.

Rick Brewster on May 6, 2008 4:40 AM

Zest has been modeled after JFace, and all the Zest views conform to the same standards and conventions as existing Eclipse views. This means that the providers, actions and listeners used within existing applications can be leveraged within Zest.

The Zest project also contains a graph layout package which can be used independently. The graph layout package can be used within existing Java applications (SWT or AWT) to provide layout locations for a set of entities and relationships.