| Best practice from making programmatic changes to part from handler? [message #1753880] |
Sat, 11 February 2017 14:09 |
 Andreas Sewe
Messages: 111
Registered: June 2013 |
Senior Member |
|
|
Hi,
consider the following simple scenario: There is a part whose view menu contains two (radio) menu items: "Green" and "Red". When the user selects "Green", the part's Composite should get get background color, if the user selects "Red" it should turn red. Simply, right?
With Eclipse 3.x, this was rather straightforward. In your MyViewPart.init(IViewSite) method, you do viewSite.getActionBars().getMenuManager() and add a couple of (anonymous) IActions which keep an reference to the MyViewPart instance and can call a custom method like changeColor on it.
With Eclipse 4, things have changed: You define your view menu declaratively as a Menu with two (Radio-typed) Direct Menu Items. Now the challenge is how to make the changes to MyViewPart. While it's easy to get the corresponding MPart injected, a handler like the following looks rather kludgy:
@Execute
public void execute(MItem item, MPart model) {
if (item.isSelected()) {
MyViewPart part = (MyViewPart) model.getObject();
part.changeColor(SWT.GREEN);
}
}
At least to me, the cast to MyViewPart looks like a rather bad practice.
Unlike the MPart, the corresponding MyViewPart is unfortunately not automatically inserted into the context, so the handler can't get the MyViewPart injected directly.
Of course, the MyViewPart could simply programmatically insert itself into the IEclipseContext, so that the handler could later retrieve it. But this explicit context manipulation looks like a bad practice as well: MyViewPart IMHO looses some of its "POJO-ness," as it needs to interact directly with the framework (via IEclipseContext).)
The best solution I could so far come up with is to declaratively define a context variable for my part descriptor and then set that variable in the handler:
@Execute
public void execute(MItem item, IEclipseContext context) {
if (item.isSelected()) {
context.modify(MyPartView.CTX_COLOR, "green");
}
}
While the handler would still need to touch the IEclipseContext, the part implementation wouldn't:
@Inject
public void onColorChange(@Named(CTX_COLOR) String color) {
...
}
Thus, the larger class (MyViewPart) remains oblivious to the framework; only the smaller handler class is "compromised."
While the above seems to the a better practice, it wouldn't consider it good. It still i rather cumbersome, not least because you need to virtually identical handlers. I hence wonder what the real best practice is here. Any pointers are greatly appreciated.
PS: Sorry for the long post, but documentation is still a bit thin and I couldn't find this discussed elsewhere.
|
|
|
Powered by
FUDForum. Page generated in 0.02879 seconds
] 
Search
Help
Register
Login
Home
