Well, I'd like to comment on this actually
I think using wires is something very important in some cases. For example if you implement an If statement. You create a YES and NO event and plug that as transition for your state, and from there you progress through your fsm.
the benefit of this for me is that I reuse the YES and NO event within my fsm, and keep the verbose within the state title. So I end up with a clear flow of what this fsm is achieving. If you only rely on global events, then it can become almost impossible to understand how that all works in 6 month time because everything is loose.
On complex project, for a given state you might request the system to perform differently. The problem with using only global events is that you loose that "state": how would you know that a particular global event needs to be active or inactive: you end up checking for this on each and every global events. if you use wiring, you can safely define several different behavior for the same system by simply triggering a top most global event that itself define the state of the system.
Another good reason to wire things up is during playback and debug, you can follow the flow. If you only use global events,it is impossible to know from where it just came out.
I have attached a screenshot of an fsm that shows how wires can help building complex behavior with only generic events like YES NO DONE, etc. This prevents ending up with hundreds of global events with no real added benefit cause each would serve a too narrow purpose. When I reach the end of this flow ( "carry on trip in" or "robot top grippers needs to come in" ) that's when I trigger global events. And I also use a global event to actually start the routine "ENGAGE ROBOT PIPE".
This flow is one of several dozens other similar processes defined in that system. During testing and approval. I have to react fast to questions like: how does it actually performs in a particular situation: If it's wired, I can simply look and most of the time don't even need to run the thing, cause there are visual evidences.
So yes. Global events are nice and convenient, but they should carry on a clear message meant to be global. In you particular case, this is perfect, but you should be careful not to extrapolate and only rely on such technic for bigger fsm and more complex behavior.
I do use global events a lot, but when I need to shout to the system really
I have attached an fsm acting as a repository of events. This repository is used for a referencing, so that if I want to implement a listener for a certain type of event, I know where they are all described ( and I don't have to search the actual fsm that triggers it). Note that this fsm do not fire itself these events, it's only a "listener". For example this can be the root for updating the user interface, logging things in a file or triggering sound effects etc etc.
What do you think?