Eclipse 4 RCP Part class best practices
-
23-07-2021 - |
题
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.
解决方案
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.