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.
On 15-Jul-2013, at 2:06 PM, Paul Elder <[email protected]> wrote:
> Tom:
>
> Can you point me to a working example? I'd like to try this out.
>
> Paul
>
>
>
>
> From: Tom Schindl <[email protected]>
> To: E4 Project developer mailing list <[email protected]>,
> Date: 07/10/2013 11:26 AM
> Subject: [e4-dev] Designflaw in our ExtendedObjectSupplier system
> Sent by: [email protected]
>
>
>
> 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
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
