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.