[e4-dev] Designflaw in our ExtendedObjectSupplier system

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

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