如何将当前的替代和母体状态从春季史坦马钦金出发?

发布于 2025-01-22 10:20:22 字数 1380 浏览 2 评论 0原文

我正在运行一个近弹簧statemachine,并且 - 经过默认取代的iNital过渡到状态后 - 想要使用statemachine.getstate()。麻烦是,它只会给我父母状态,我找不到一种明显的方法来检索父态和子状态。

机器具有状态构造的:

    StateMachineBuilder.Builder<ToolStates, ToolEvents> builder = StateMachineBuilder.builder();


    builder.configureStates()
       .withStates()
          .initial(ToolStates.UP)
          .state(ToolStates.UP, new ToolUpEventAction(), null)
          .state(ToolStates.DOWN                
          .and()
       .withStates()
          .parent(ToolStates.UP)
          .initial(ToolStates.STOPPED)
          .state(ToolStates.STOPPED,new ToolStoppedEventAction(), null )
          .state(ToolStates.IDLE)
          .state(ToolStates.PROCESSING,
                 new ToolBeginProcessingPartAction(),
                 new ToolDoneProcessingPartAction());

    ...

    builder.build();

toolstatestoelevents只是枚举。在客户端类中,在上面运行构建器代码后,statemachine以statemachine.start();启动,当我随后调用statemachine.getState().getID(); >它给了我up。在电话之前,没有任何事件发送给Statemachine。 我一直在春季史坦马辛文档和示例上下来。我从调试中知道,两种状态的输入操作 up 和已被调用已被调用,所以我假设它们都是“活动”的,并且希望呈现两种状态在查询statemachine时。有什么干净的方法可以实现这一目标吗?我想避免将替代从动作类中的某个地方存储,因为我相信我首先将所有州管理问题委派给了freakin statemachine,我宁愿学习如何将其API用于此目的。

希望这是令人尴尬的明显的东西……

任何最欢迎的建议!

I am running a hierachical Spring Statemachine and - after walking through the inital transitions into state UP with the default substate STOPPED - want to use statemachine.getState(). Trouble is, it gives me only the parent state UP, and I cannot find an obvious way to retrieve both the parent state and the sub state.

The machine has states constructed like so:

    StateMachineBuilder.Builder<ToolStates, ToolEvents> builder = StateMachineBuilder.builder();


    builder.configureStates()
       .withStates()
          .initial(ToolStates.UP)
          .state(ToolStates.UP, new ToolUpEventAction(), null)
          .state(ToolStates.DOWN                
          .and()
       .withStates()
          .parent(ToolStates.UP)
          .initial(ToolStates.STOPPED)
          .state(ToolStates.STOPPED,new ToolStoppedEventAction(), null )
          .state(ToolStates.IDLE)
          .state(ToolStates.PROCESSING,
                 new ToolBeginProcessingPartAction(),
                 new ToolDoneProcessingPartAction());

    ...

    builder.build();

ToolStates and ToolEvents are just enums. In the client class, after running the builder code above, the statemachine is started with statemachine.start(); When I subsequently call statemachine.getState().getId(); it gives me UP. No events sent to statemachine before that call.
I have been up and down the Spring statemachine docs and examples. I know from debugging that the entry actions of both states UP and STOPPED have been invoked, so I am assuming they are both "active" and would want to have both states presented when querying the statemachine. Is there a clean way to achieve this ? I want to avoid storing the substate somewhere from inside the Action classes, since I believe I have delegated all state management issues to the freakin Statemachine in the first place and I would rather like to learn how to use its API for this purpose.

Hopefully this is something embarrasingly obvious...

Any advice most welcome!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

月寒剑心 2025-01-29 10:20:22

文档描述getStates()

https://docs.spring.io/spring-statemachine/docs/current/api/org/springframework/statemachine/statemachine/state/state/state/state/state.html

java.util.Collection<State<S,E>>    getStates()
Gets all possible states this state knows about including itself and substates.

stateMachine.getState().getStates();

The documentation describes getStates():

https://docs.spring.io/spring-statemachine/docs/current/api/org/springframework/statemachine/state/State.html

java.util.Collection<State<S,E>>    getStates()
Gets all possible states this state knows about including itself and substates.

stateMachine.getState().getStates();
梦在深巷 2025-01-29 10:20:22

在SMA的最有用的建议之后将其包装好:事实证明statemachine.getState()。getStates();在我的情况下确实返回四个元素的列表:

  • a

    a statemachinestate < /code>包含up停止

    的实例

  • 三个objectState 包含indle的实例,<代码>停止和处理
    分别。

这使我暂时可以使用以下解决方案前进:

public List<ToolStates> getStates() {
    List<ToolStates> result = new ArrayList<>();
    Collection<State<ToolStates, ToolEvents>> states = this.stateMachine.getState().getStates();
    Iterator<State<ToolStates, ToolEvents>> iter = states.iterator();
    while (iter.hasNext()) {
        State<ToolStates, ToolEvents> candidate = iter.next();
        if (!candidate.isSimple()) {
            Collection<ToolStates> ids = candidate.getIds();
            Iterator<ToolStates> i = ids.iterator();
            while (i.hasNext()) {
                result.add(i.next());
            }
        }
    }
    return result;
}

通过流媒体和过滤,这可能会更加优雅,但是目前可以解决问题。我不太喜欢它。这是很多容易出错的逻辑,我必须看看它是否会在将来成立 - 我想知道为什么春季statemachine中没有功能,这给了我全部当前活动 状态,而不是给我一切可能的一切,并强迫我用外部逻辑戳入它...

to wrap it up after SMA's most helpful advice: turns out the stateMachine.getState().getStates(); does in my case return a list of four elements:

  • a StateMachineState instance containing UP and STOPPED

  • three ObjectState instances containing IDLE, STOPPED and PROCESSING,
    respectively.

this leads me to go forward for the time being with the following solution:

public List<ToolStates> getStates() {
    List<ToolStates> result = new ArrayList<>();
    Collection<State<ToolStates, ToolEvents>> states = this.stateMachine.getState().getStates();
    Iterator<State<ToolStates, ToolEvents>> iter = states.iterator();
    while (iter.hasNext()) {
        State<ToolStates, ToolEvents> candidate = iter.next();
        if (!candidate.isSimple()) {
            Collection<ToolStates> ids = candidate.getIds();
            Iterator<ToolStates> i = ids.iterator();
            while (i.hasNext()) {
                result.add(i.next());
            }
        }
    }
    return result;
}

This maybe would be more elegant with some streaming and filtering, but does the trick for now. I don't like it much, though. It's a lot of error-prone logic and I'll have to see if it holds in the future - I wonder why there isn't a function in the Spring Statemachine that gives me a list of the enum values of all the currently active states, rather than giving me everything possible and forcing me to poke around in it with external logic...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文