Review TBlEventTarget

[tinchodias]

In short, this trait implements the API of the subject (or publisher) in the Observer Design Pattern, specialized on Bloc elements. This API could directly belong to BlElement, but it exists as a trait so other objects can benefit, being polymorphic with an element.

=> First critic: This may be wrong/misleading... See #355, for example.

The only requirement from this trait is eventDispatcher, where each user can choose from 3 available dispatchers.

The trait comment can be improved. It says: "I implement a basic infrastructure of event management. Any object that needs to be able to handle events should use me.".

The API has:

• hasNextEventTarget and nextEventTarget hooks, that are overridden by BlElement to create a BlEventDispatcherChain with the parent elements up to the root.
• add/remove/access handlers (subscribers)
• add/remove/access filters (high-priority subscribers)
• add/remove/access shortcuts (subscribers to keyboard events)

=> Second critic: Do we need the name "filters" to differentiate event handlers that have a higher-priority from the ones with regular-priority? they are mostly used in debugging and testing code. Maybe something like addHandlerFirst: and addHandlerLast: are enough.

=> Third critic: Shortcuts API narrows the meaning of TBlEventTarget... users should only be publishers that may dispatch keyboard events.

[tinchodias]

These are the users of TBlEventTarget:

I consider almost all of them don't fit with the meaning of TBlEventTarget. Almost all only need an Announcer. Even BlSpace, I'm not sure it needs to be a user. We removed some addChild* API in BlSpace that was making it partially polymorphic with BlElement. We removed it because it was only redirecting the message to the space's root. So it may be a similar case with TBlEventTarget in space.

---

EDIT: the other option is to remove shortcut API from TBlEventTarget to make it more general, and then it would make sense to have all those users.

[plantec]

Regarding filters: they are not high-priority handlers.
A filter is for managing descending events whereas a regular handler can manage bubbling events.
We need these two ways of handling events.
So a filter can be used to react to an event ** before ** its identified target receives it.
This is how mouse picked outside are managed in toplo (and in brick too).
The name 'filter' is maybe confusing but finally it makes sense regarding the use of event filters.
I guess that only event created through the BlSpaceFrameEventPhase can have descending/bubbling phases (mouse down/up)
User defined BlEvent are in fact Announcements that can be managed with event dispatchers.

Event managing requires two kind of api, (1) for registering handlers and (2) for event sends management (finding and invoking handlers).
We can have better separation of concerns regarding event registering but it may be much more difficult for the event sends management.
maybe possible:

• better separation of concerns for handler registering with a TBlSimpleEventTarget to allow whatever object to register handlers for user defined events, a TBlEventTarget for all event kinds (for BlElement) and TBlShortcutTarget for registering shortcuts.
• currently, the algorithms for finding handlers/shortcuts are nested, maybe optimizations are possible ...

[plantec]

thinking a bit more, having TBlSimpleEventTarget seems useless since the api for registering handlers is the same whatever the event kind

[plantec]

please, keep the Bloc event API consistent as it is now.
Only BlEvent, no Announcement.
Any object can become an event target.
It is definitively useful (and elegant)

[tinchodias]

Regarding filters: they are not high-priority handlers. A filter is for managing descending events whereas a regular handler can manage bubbling events. We need these two ways of handling events. So a filter can be used to react to an event ** before ** its identified target receives it. This is how mouse picked outside are managed in toplo (and in brick too). The name 'filter' is maybe confusing but finally it makes sense regarding the use of event filters. I guess that only event created through the BlSpaceFrameEventPhase can have descending/bubbling phases (mouse down/up) User defined BlEvent are in fact Announcements that can be managed with event dispatchers.

You are right about filters in BlBubblingEventDispatcher. I was right about BlDirectEventDispatcher but I wasn't precise (as I didn't specify it). I still consider that a BlDirectEventDispatcher is an Announcer+filters+shortcuts, and it is used in some cases where filters and shortcuts don't make sense, such as in animations (BlBaseAnimation).

I think think more on it, thanks for your feedback

[plantec]

I don't understand the interest of filters in case of a non-bubbling event dispatcher :)
ok, a BlBaseAnimation don't need filters and shortcuts, but does it need event or announcements ?