Allow unregistering of handlers on a per-event class basis about gwteventbinder HOT 5 OPEN

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.

from gwteventbinder.

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?

from gwteventbinder.

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.

from gwteventbinder.

@christiangoudreau, can you provide more concrete examples for your use cases?

from gwteventbinder.

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

from gwteventbinder.