spring-projects
Feature to check if the statemachine would currently accept an event
As discussed here, it would be nice if it was possible to check if the statemachine would currently accept an event (like sendEvent(...) but without triggering a transition).
Use case:
I have some UI buttons which send events to the state machine. My use case is to enable/disable these buttons depending on whether the state machine would accept their event or not.
Just adding some notes here:
- Feature requested is ok at least in terms of internal machine functionality, I'm just not sure if a public api should expose it. This then raises a question how user can access it.
- Some planned SPI's for comm within a state machines(orthogonal regions) definitely would benefit to ask this question from other machines.
- Problem with this is that testing if machine accepts an event only gives answer exactly at that moment thus doesn't guarantee if machine accepts that event any time in a future.
I'm kinda leaning toward a more useful api feature like "what a machine would do if I'd send an event E with headers H".
Problem with this is that testing if machine accepts an event only gives answer exactly at that moment thus doesn't guarantee if machine accepts that event any time in a future.
even if the event is not accepted by the SM, from the definition itself (thinking about this) it should be possible to enumerate the next possible/available transitions in a certain state ?
@silviuilie yes you are quite right in your comment and it's a reason why I've kept this ticket open instead of closing it as "can't do it". We're gradually getting more features into a state machine and I'm hoping these will eventually give us a better model to predict what a state machine might do with an event, thus giving a prediction what might be a result of a particular behaviour of an event. This is a very difficult topic because we're kinda trying to do a timemachine to look in a future :o
I would also like to see something in that direction. I implemented a proof-of-concept that I can use spring-statemachine alongside with jpa and spring-data-rest here (https://github.com/otrosien/spring-statemachine-jpa), but a lack of accessing "acceptable" events given the current state of the state machine is forcing me to duplicate parts of the logic into the link generation, which I'd like to avoid.
This has been low priority ticket mostly because it is fundamentally impossible to predict a future. Taking a simple flat one level machine having no guards for transitions, it is possible to predict what a machine would do but anything beyond that things get into a can of worms. Especially with complex nested states, event can by handled on different machine dynamically and this is something shown in a showcase sample.
If we use time to make a prediction engine of some sort, we could get pretty close by knowing what would happen in a time of asking this question but it cannot be guaranteed that event will be accepted when it is actually sent into a machine because conditions in between those two times may be different.
Just to be on the same page: I'm not talking about predicting the future state of the machine. To simplify things, it does not even necessarily have to take guards into considerations in the first step. It's only about finding the transitions given the current state. From the UML model this looks pretty simple...
Indeed, maybe we can try something simpler like just looking transitions and finding events from there.
Implemented as you suggested for a simple (non-nested) state machine here: https://github.com/otrosien/spring-statemachine-jpa/blob/master/src/main/java/com/example/ContextObjectResourceProcessor.java
I am not really in the middle of discussion but my 2 cents.
In this blog, https://mehmetsalgar.wordpress.com/2015/12/14/ajax-spring-web-flow-and-spring-state-machine/, when I create State Machine from the UML model, I also create a Java Enumeration for all the acceptable events\triggers for the states.....
This way a developer that doesn't have that much knowledge about the design of the State Machine can exactly see which Events/Triggers are available for this states (UML States incoming transitions contains this information).
Was this ever implemented? This seems to be a standard requirement that we show the list of available events as UI buttons given the current state. For example, OSWorkflow had this as an API get available actions()
