| I have this issue in a system where we've created a new annotation @ActiveEditor to cause a lookup to be done in the IEclipseContext of the active editor as determined by some scope (e.g., a window, a set of windows, or the workbench). We have to use
@ActiveEditor @Named("guaranteed-non-existant-variable")
whenever we attempt to inject something that may or could be in the source context.
There's a related issue lurking here too with respect to an injection site with two annotations for two different ExtendedObjectSuppliers. Do we pick a winner? Is there some to reconcile? I had a case, but it slips my mind now and I was able to restructure the code in an equally elegant way.
Brian. Tom:
Can you point me to a working example?
I'd like to try this out.
Paul
From:
Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
To:
E4 Project developer
mailing list <e4-dev@xxxxxxxxxxx>,
Date:
07/10/2013 11:26 AM
Subject:
[e4-dev] Designflaw
in our ExtendedObjectSupplier system
Sent by:
e4-dev-bounces@xxxxxxxxxxx
Hi,
While giving a e4 workshop we discovered what I think is a big flaw in
our ExtendedObjectSupplier system making it unusable for @UIEventTopic
and @Preferences.
Suppose the following implementation:
public class MyPart {
public void init(IEclipseContext context) {
ListViewer v = ....
v.addSelectionChangedListener( new .... {
....
context.set(Person.class,
p);
}
}
@Inject
@Optional
public void personCreated(@UIEventTopic("person/new")Person
p) {
// ...
}
}
public class NewPersonHandler {
@Execute
public void execute(IEventBroker b) {
Person p = ...
b.send("person/new",p);
}
}
Things you'll observe:
a) modifying the selection will call personCreated
b) personCreated will only receive the object created in
NewPersonHandler the selection has not changed afterwards the method
is called but the value passed is the one written to the context
The only solution to this problem is to make the event handler look like
this:
@Inject
@Optional
public void personCreated(@UIEventTopic("person/new")
@Named(akeythatsneverused) Person p) {
// ...
}
The reason for this wrong behavior is that the core DI system has no
ideas about the extended supplier and so it is the main source for the
look up, in case this look up succeeds because someone pushed something
exactly below this key in the context (or in the parent hierarchy) the
event receiving is broken.
I'm not yet sure what needs to be done to fix this but without this our
nice @Preference and @*EventTopic solution is unusable.
Tom
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|
