Open LaiaPerez88 opened 3 years ago
@thomas-advantitge, Booster annotations are just functions so you could define your event handler class and perform a map operation over an array of events:
class MyEventHandler {
// event handler definition ...
}
for const event of [EventA, EventB, EventC] {
EventHandler(event)(MyEventHandler))
}
In this code above we’re defining just one event handler class that will get all of the events in runtime. In order to let Booster know that this class can be used for different event classes, we are using the @EventHandler decorator as a standalone function to register this class as an event handler for all of the events. Note that this is a workaround, and first-class support for this could be added to the framework relatively easily.
Could maybe be solved by the previous question.
Goal: let an event handler listen to all events so they can be filtered and act on at runtime instead of compile time. Example: passing
DossierCreated
PartyCreated
DocumentCreated
events to a search engine to index text fields for universal search. It would be nice to decouple these functional domains (dossier, party, document) from the search module. The search module should just being able to receive all kinds of events and act on specific ones which could be configured at runtime.