Wildcard transitions

[Alexey Morozov]

Hello!

I'd like to ask/ascertain how "wildcard transitions" are supposed to work.

Suppose we have states, events and state machine description defined like this:

    enum State {
       A, B, C
    }

    enum Event {
      ToB, ToC
    }

    @States({
        @State(name="A", entryCallMethod="entryStateA", exitCallMethod="exitStateA"),
        @State(name="B", entryCallMethod="entryStateB", exitCallMethod="exitStateB"),
        @State(name="C", entryCallMethod="entryStateC", exitCallMethod="exitStateC"),
     })
     @Transitions({
        @Transit(from="A", to="B", on="ToB", callMethod="fromStateAToStateBOnGotoB"),
        @Transit(from="*", to="C", on="ToC", callMethod="fromAnyStateToStateCOnGotoC"),
     })
     interface DeclarativeStateMachine extends StateMachine<DeclarativeStateMachine, State, Event, Integer> {
        ... method declarations...
     }

Does this FSM declaration mean that

1. when the SM is in A state, and ToB event received, then the SM is switched to B state and all appropriate methods are called?
2. And if the SM is in _any_ state and ToC event arrives then the SM is switched to C state and  all suitable methods are called?

If the answer is "yes, the SM is supposed to work exactly like described above", then it seems that I've discovered a bug.
In this case the bug is in StateMachineBuilderImpl.installDeferBoundAction(DeferBoundActionInfo<T, S, E, C> deferBoundActionInfo)
The current (master) implementation of the method doesn't add all possible transitions (in our example: from A, B and C to C), but rather
adds the action from the wildcard transitions to pre-exisiting "completely defined" transitions which match the wildcard.
Thus with the current implementation these wildcard transitions are only usable to enrich existing SM behavior.

Or maybe this is expected and intended? Please explain.

Best regards,
Alexey

[He Henry]

Hi,

This is expected behavior. Here is description about "wildcard" usage.

Since 0.3.1, there is another way to define these extension methods(AOP-like methods) which is through fluent API (thanks suggestion from vittali), e.g.

// since 0.3.1
builder.transit().fromAny().to("C").on("ToC").callMethod("fromAnyToC"); // the same effect as add method transitFromAnyToCOnToC in your state machine
builder.transit().from("B").toAny().on("ToC").callMethod("fromBToAny"); // the same effect as add method transitFromBToAnyOnToC in your state machine
builder.transit().from("B").toAny().onAny().callMethod("fromBToAny");   // the same effect as add method transitFromBToAny in your state machine

Basically, it is just the other option to declare AOP-like methods which is actually attach the action methods to any matched and already existed transitions but not to create any new transitions. 

Thanks,

Henry

在 2014年7月25日星期五UTC+8下午8时07分52秒，Alexey Morozov写道：

[Alexey Morozov]

Hi!

Ok, then the question is: wouldn't it be useful to have some kind of "catchall" method/technique? Such a method would save a SM from having a lot of almost same lines,
when e.g. a given event unconditionally moves the SM into a particular state, regardless of its source state. Also this could help in implementation of "safe-guards" when an event
set is enriched independently and a SM should at least notify that something unexpected happens (sure, this could be also implemented other ways).

And another question: are there plans to implement a declarative API (i.e. via annotations) analogs for multiple-transitions-at-once methods like "onEach()" etc?

Best regards,
Alexey

[He Henry]

1. wouldn't it be useful to have some kind of "catchall" method/technique?

Actually, there is always a "catchall" method afterTransitionDeclined/afterTransitionEnd in AbstractStateMachine,  you can always override these methods, e.g. fire fallback event when transition declined.

2. Such a method would save a SM from having a lot of almost same lines, when e.g. a given event unconditionally moves the SM into a particular state, regardless of its source state.

multiple-transitions-at-once will help you for this case, e.g. builder.transitions().fromAmong(State.B, State.C, State.D).to(State.A).on(Event.AnyToA)...

3. And another question: are there plans to implement a declarative API (i.e. via annotations) analogs for multiple-transitions-at-once methods like "onEach()" etc?

Yes, next release.

I am not quite understand the problem about 'safe-guards' enriched independently and SM should at least notify that something unexpected happens. May be you can give me an example.

Thanks,

Henry

在 2014年7月28日星期一UTC+8下午3时18分52秒，Alexey Morozov写道：

[Alexey Morozov]

1. accepted.

afterTransitionDeclined/afterTransitionEnd _seem_ to me a bit more wide than I usually need, but certainly the problem of the "catchall" case can solved via these methods

2. Sure I could use this new API. It's a bit inconvenient [for me] if there're _many_ states from each to perform such a jump, so the code chunk becomes a bit, ehhm-m, overflown
but technically it's Ok. With [planned] possibility to use the declarative API as well this becomes even more suitable I guess.

3. Suppose a new kind of event is added, and the SM doesn't know anything about this event. Certainly reporting such cases in overriden `afterTransitionDeclined` would help
to notify a developer that something is going on a way he/she didn't expect. But also there could be valid/expected reasons to decline a transition so in `afterTransitionDeclined`
should handle these cases differently.

Certainly all these cases are not a must-have, they all can be handled using existing API. It's all matter of tastes and convenience (which often heavily depends on particular tastes)

Thanks,
Alexey

понедельник, 28 июля 2014 г., 14:58:46 UTC+7 пользователь He Henry написал: