Eclipse RCP: Where should I keep my model objects and how do they talk to the views?

Question

In Eclipse RCP way of doing things, where should I keep my model objects? And when they are loaded or changed, how should they talk to the views?

I am attempting to port my existing application to Eclipse RCP. It could be viewed as an IDE-like application: I open a file, which contains links to source files. The source files are displayed in the tree view. I can edit the source, and build the sources into some output...

For example, when I handle the Open command, where would I create the model object so my views can see them? I'd rather avoid the use of singleton manager class, but that maybe the simplest way.

Interesting code I found browsing JDT's source code are JavaCore, JavaModel, JavaModelManager. and JavaProject.

---

IProject[] projects= ResourcesPlugin.getWorkspace().getRoot().getProjects();

---

public static IJavaProject create(IProject project) {
    if (project == null) {
        return null;
    }
    JavaModel javaModel = JavaModelManager.getJavaModelManager().getJavaModel();
    return javaModel.getJavaProject(project);
}

---

Related:

• How do you communicate between eclipse declarative services and Views (ContentProviders)
• Make your Eclipse applications richer with view linking

Answer 1

I believe this is best achieved through Listeners.

Your data (model) is in private package, and only Interfaces of those data are exposed in a public package.

You will find in this wiki section the principle, but also concrete examples here.

---

Regarding the model, an osgi-like approch would be to use a host plugin as the accessible object. i.e:

MyPlugin.getDefault().getModel()

This will allow you to setup/dispose the model along with the plugin lifecycle.

If the model is in one plugin, it can define extension points for listeners. A view can extend these extension points which are then automatically registered in the loading of the Model plugin. The views can query the model for the required information as soon as they get the first message from the model.

A good example of data binding can be found in this article.

Answer 2

We tend to use IEditorParts to store keep a copy of the model (derived from the IEditorInput).

If a view needs to know about the model, then use the ISelection framework and focus to move the model around from the editor to the view.