Re: [e4-dev] Designflaw in our ExtendedObjectSupplier system

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

This was a made up sample but you can test this with the problem
mentionned in 398728 which is simply a variation of the described problem.

Tom

On 15.07.13 20:06, Paul Elder wrote:
> 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
>