Performance optimization: Fine-tune EcaStorage::loadByEvent
Problem/Motivation
We have already optimized the loading of ECA configurations in the way that only configurations are loaded that make use of the according event class. This is already a very good optimization and we can safely keep it.
Some sites might want to use ECA to model their whole business logic with it. Dealing with system events as entrypoints may be fine, but for more fine-grained control of business-related events, the action for triggering a custom event could be one of the main ones being used.
A custom event is always the same event class, and this may lead to the situation that a lot of configurations would be loaded for custom events but only a fraction of them would apply in many cases. Therefore I think it makes sense to extend EcaStorage::loadByEvent a little bit so that only configurations would be loaded when actually needed.
Steps to reproduce
Proposed resolution
Within EcaStorage::loadByEvent we currently use the class name of an event to group used ECA configurations. We could introduce a new interface for event classes that provides a (hash?) value for the grouping. The class for a custom event may then use its assigned event ID to be used as grouping criteria. For events that are not implementing that interface, we just keep the current logic (by using the class name).
Remaining tasks
Discuss and implement.