fiammybe
commented
6 years ago I agree with you that in order to make the system more flexible, we absolutely need to be able to trigger or be triggered by events in other modules or objects. There was a start with icms_Events, but it isn't really used to its potential.
I was afraid that the cakephp code would require us to include large parts of cakephp, but it seems that isn't the case. It looks easy to implement so I would go for that.
If this event handling is done well, it can make parts of the code much easier. For example the registration procedure could be split in several parts, and the conclusion of each part could be a different event. That way, you could for example add a validation to a step by just subscribing the validation to an event, all withouth having to change your login code.
github-actions[bot]
MekDrop
Currently we have semi implemented events management class. Some classes in our core use own events handlers (f.e. ipf handler). So, there are some extra code and pain how to manage all this related code. My solution is use some events management library.
I think cakephp/event looks best for us. It could be used both in other classes and as static class. Maybe two things that it misses and could be useful for us are wide events triggering (like phpleague/events has) and non-blocking events handling. But that we could leave for a while not implemented in our core.