Eventbinding in abstract classes.

[buckligebrotspinne]

Hello,

we successfully used the EventBinder in our project. All worked well but we have discovered one disadvantage. Currently we cannot define a EventHandler in abstract classes which will be extended by our concrete presenter implementations. This is very awkward. Our current workaround for this is that we bind the event, which should be normally handled by the abstract class, in our extending presenter implementations and from there we call a method from the abstract class to handle/work with the events context.

Is it possible to bind the event handler methods in the abstract classes after all or do we have to work with our workaround?

With best regards Marco

[ekuefler]

@gokdogan, what do you think of this suggestion? This seems like a pretty reasonable request to me - Guava's eventbus appears to look at the parent's @Subscribe methods, and this would also be consistent with registering this as a handler on the EventBus as in eventBus.addHandler(ClickEvent.TYPE, this) when ClickHandler is implemented in the superclass.

Should be a fairly easy change to make and isn't likely to have serious backwards compatibility issues if you think it's a good idea.

[gkdn]

Agreed. I actually didn't know it wasn't looking at the super class while binding the methods.

There might be some compatibility issues but I think we should still change the behavior.

[buckligebrotspinne]

Hello,

that would be great if you can implement it.

Thank you in advance.

Marco

[ekuefler]

I just pushed f908a36b24a5e894e8f9f6957e380feb67b50a1d implementing this, let me know what you think.

It's not quite as easy as just iterating up the class hierarchy and binding in the same way as is done for the current class, there are some subtle issues around how overrides should work. As currently implemented, I'm generating one handler per unique method signature found in the hierarchy. This should make overridden event handlers work correctly, since the overridden method will only be invoked once and it will be dispatched to the subclass. However, defining another handler for the same event (but a different method name) in a subclass will mean that the event will be dispatched to both the subclass and the superclass handler.

Try it out, if it seems like this gives the behavior we want I can push out a new version to Maven soon.

[buckligebrotspinne]

Hello,

i have tested the branch for "our" code and it works! Thank you for the fast response and implementation!

I´m looking forward for the new version. :-)

With best regards Marco