Where to store "global" data in Eclipse RCP Application?

Question

I'm a beginner with Eclipse RCP and I'm trying to build an application for myself to give it a go. I'm confused about how one actually goes about handling model objects. None of the examples I can find deal with the problem I'm having, so I suspect I'm going about it the wrong way.

Say I need to initialise the application with a class that holds authenticated user info. I used my WorkbenchWindowAdvisor (wrong place?) to perform some initialisation (e.g. authentication) to decide what view to show. Once that's done, a view is shown. Now, that view also needs access to the user info I had earlier retrieved/produced.

The question is, how is that view supposed to get that data? The view is wired up in the plugin.xml. I don't see any way I can give the data to the view. So I assume the view has to retrieve it somehow. But what's the proper place for it to retrieve it from? I thought of putting static variables in the IApplication implementation, but that felt wrong. Any advice or pointers much appreciated. Thanks.

Answer 1

The problem you are facing here is in my opinion not RCP related. Its more an architectural problem. Your view is wired with business logicand! The solution can be done by two (common) design-patterns:

1. Model-View-Controler (MVC)
2. Model-View-Presenter (MVP)

You can find plenty information about this in the web. I am going to point a possible solution for your particular problem using MVP.

You will need to create several projects. One is of course an RCP plugin, lets call it rcp.view. Now you create another one, which doesnt make UI contributions (only org.eclipse.core.runtime to start with) and call it rcp.presenter. To simplify things, this plugin will also be the model for now.

Next steps:

1. Add the rcp.presenter to the dependencies of rcp.view (its important that the presenter has no reference to the view)
2. Export all packages that you are going to create in the rcp.presenter so they are visible
3. In rcp.presenter create an interface IPerspective that has some methods like (showLogiDialog(), showAdministratorViews(User user), showStandardViews(User user))
4. Create a class PerspectivePresenter that takes IPerspective in the constructor and saves it in an attribute
5. In rcp.view go to your Perspective, implement your interface IPerspective, and in the constructor create a new reference presenter = new PerspectivePresenter(this)
6. call presenter.load() and implenent this in the presenter maybe like this

code:

public void load()
{
  User user = view.showLoginDialog(); // returns a user with the provided name/pw
  user.login(); // login to system/database
  if(user.isAdministrator())
    view.showAdministratorViews(user);
  else
    view.showStandardViews(user);
}

As you can see, the view just creates a reference to the presenter, which is responsible for all the business logic, and the presenter tells the view what to display. So in your Perspective you implement those interface functions and in each one you can set up your Perspective in a different way.

For each View it goes in the same way, you will need a presenter for the view which performs operations and tells the view (using the interface) what to display and passing down the final data. The view doesnt care about the logic. This is also very usefull when using JFace-Databindings (then only bound data is passed to the view). For example, the WorkbenchWindowAdisor will just create everything that is needed in the application. Other views, perspectives, then can enable/disable menus and so on depending on the data they got (like when isAdministrator you might want to enable an special adminMenu).

I know this is quite a heavy approach, but the Eclipse RCP is designed for big (as the name says rich) applications. So you should spend some time in the right architecture. My first RCP app was like you described...I never knew where to store things and how to handle all the references. At my work I learned about MVP (and I am still learning). It takes a while to understand the concept but its worth it.

You might want to look at my second post at this question to get another idea on how you could structure your plugins.