Open spg opened 11 years ago
If we let you to remove handlers by event then the next thing will be to provide an API to add them back. That would just make these more complicated. If you need to manage an event independently from the rest of the class, best thing to do is to add handlers for it without EventBinder.
Yeah, I agree with Goktug here. It's a lot easier to reason about how your class will work when either all @EventHandler methods are active or none of them are. Selectively removing handlers can make for really frustrating debugging when you're trying to figure out why one of your handlers isn't working and the rest all are.
If you want to be able to remove an individual handler, there's no reason you can't add it directly to the event bus and manage it outside of EventBinder - mixing @EventHandlers with normal calls to addHandler works fine. That way you can remove individual registrations while still having confidence that things declared as @EventHandlers will continue to work reliably.
Does that solution work for you?
My opinion is different, it is not unusual to have visibility handlers that are added and removed automatically depending if something is shown or not.
I've made the proposition into a post to be able to specify the EventBinder on wich a EventHandler can be bound simply by adding a parameter inside the annotation that takes the .class of the EventBinder to register the events.
@christiangoudreau, can you provide more concrete examples for your use cases?
Dynamic places, Dynamic tabs (linked to places), other cases when you want only the visible presenters to update when an event is thrown. (Servers update) Etc.
Doesn't happen often in simple apps though
According to EventBinderTest, when
presenter.handlerRegistration.removeHandler()
is called, all handlers are unregistered, regardless of the event's type.It would be awesome if one could unregister only handlers of a particular event type, e.g.:
presenter.handlerRegistration.removeHandler(SecondEvent.class);