Eclipse 4 RCP Part class best practices

Question

I'm learning the new Eclipse 4 RCP platform and I just ran into an interesting issue.

Suppose I'm designing a Part class for an MPart defined in my Application.e4xmi:

public class SomePartView {
    private Text someText;
    private Button someButton;

    @PostConstruct
    public void createControls(Composite parent) {
        parent.setLayout(new GridLayout(3, false));
        someText = new Text(parent, SWT.BORDER);
        someButton = new Button(parent, SWT.NONE);
        someButton.setText("SomeButton");
    }

    @Focus
    private void setFocus(IEclipseContext context) {
        someText.setFocus();
    }

    // ... getters
}

I'm using WindowBuilder to create the ui but I want It to be free of any behaviorial code so I crete a class where I handle the interaction like this:

public class SomePartViewController {

    @PostConstruct
    public void addBehavior(SomePartView view) {
        view.getSomeButton().addSelectionListener(new SelectionAdapter() {
            @Override
            public void widgetSelected(SelectionEvent e) {
                // do something
            }
        });    
    }
}

Is this a good practice or I'm reinventing the wheel here and e4 already has some solution for this? If not how do I wire these classes together? I want to avoid creating instances outside of the Eclipse context. Since the official e4 documentation is rather sparse it would be nice too if someone could link me an exhaustive book or reference manual where I can find the answers.

Answer 1

I'm not sure whether I can give you a full fledged answer, but I will try to come up with some hints or remarks.

First off, only classes referenced by the application model will get dependency injection; so SomePartView will get the respective @PostConstruct executed. There is however no direct connection to SomePartViewController out of the application model, so you will not get any auto-injection.

There are methods you could realize this, e.g. by using a processor extension as described in Extending the application model or by looping in the dependency over your SomePartView and instantiating the behavior classes from there.

If I get your question right, this however would fail your main realisation purpose of dividing the view and the behaviour.

Maybe XWT is the technology you are really looking for. Here the UI is defined declaratively and Event Handlers are still implemented in Java classes. I guess that the way XWT works is already kind of a best practice, as it can be compared to the Android programming style of creating user interfaces.