danewell / stateless Goto Github PK

I have been playing with Stateless for a while, it has a good solid framework.

I am currently learning fuzzy state machine, I wonder if anyone has considered 
this enhancement to stateless.

I've cloned the repo and done the .net 4 upgrade ... feel free to pull those 
changes into your repo (I'm not sure if there's something I need to do to 
enable that, let me know)

http://code.google.com/r/joelmartinez-stateless/source/browse

Actually this is more a question than an issue :) I've asked my question on SO 
and here's the link :
http://stackoverflow.com/questions/24798110/stateless-how-to-define-the-initial-
substate-of-a-superstate

Hey,
I'm using Stateless and it's really great.
Though I'm kind of stuck right now since I need to use orthogonal regions.
You can read about it here:
http://en.wikipedia.org/wiki/UML_state_machine#Orthogonal_regions

It basically means you can be in more than one state at a time, and it can save 
a lot of code duplication.
I'm trying to figure out how to implement it on my own at the moment, but I'll 
be really glad to get some help with the design, or official support.

-Tom

What steps will reproduce the problem?
1. Create a Statemachine with substates
2. In a substate Ignore a trigger allowed in it's Superstate
3. Transition your state machine to above substate
4. Examine yourStateMachine.ToString()


The ignored trigger will be listed among the Permitted triggers even though the 
trigger won't be allowed by yourStateMachine.CanFire(substate)

Cause seem to be the union with the superstates permittedTriggers:

            public IEnumerable<TTrigger> PermittedTriggers
            {
                get
                {
                    var result = _triggerBehaviours
                        .Where(t => t.Value.Any(a => a.IsGuardConditionMet))
                        .Select(t => t.Key);

                    if (Superstate != null)
                        result = result.Union(Superstate.PermittedTriggers);

                    return result.ToArray();
                }
            }

What steps will reproduce the problem?
1. Define state with substates
2. Define entry actions for both
3. Enter the state and check the order

What is the expected output? What do you see instead?
Superstate's actions should execute first. But looking at 
StateRepresentation.Enter() they execute after substate's actions.


What version of the product are you using? On what operating system?
2.1

Please provide any additional information below.
The exist should work in the existing order - leave substate, then leave 
superstate, executing actions in this order.

On my clone, I have created the mechanism to fire a trigger and pass parameters 
to both the OnEntry and OnExit calls.  So the only difference here is that 
parameters can be passed along to all OnEntry/OnExit delegates and instead of 
just the OnEntryFrom delegates.

My use-case for stateless is a little different than the sample apps.  I am 
considering stateless to live outside the object being moved through the state 
engine.  Entry and Exit steps are seperate objects being injected at runtime, 
therefore the parameters and state steps are more loosely connected. I also 
view the parameters as 'context' and from that standpoint should be immutable 
(if only we had 'where T : immutable').

So my question is - does this approach make sense?  If so, I'll flex this to 
allow for up to four parameters (I currently only use 1 by design) and submit a 
pull request.

Thank you,
-Steve

I have included my changes to the clone named "stevehebert-fluentwf".

These changes involve allowing an arguement to be passed to the Fire method 
that is non-conditional.

This has been added to support the FluentWorkflow project as all trigger 
context is passed through as an explicit reference.

Hi,

is it possible to determine the last active state after a transition was 
triggered?

For example: Three States (S1,S2,S3) and 2 triggers (next,prev):
(I use {} to mark pre defined states)

(S1) -[next]-> (S2) -[next]-> (S3) -[next]-> {S1}

{S3} -[prev]-> {S2} -[prev]-> {S1} -[prev]-> {S3}

How can S3 determine whether the previous State was S2 or S1?

It's not actually a problem, more like a request of a future feature. :)
Hope it fits here anyway.
Thx
tobias

Self-transitions do not trigger entry or exit events. In some circumstances 
it would be handy to do so. E.g.:

machine.Configure(State.Assigned)
      .Allow(Trigger.Assign, State.Assigned)
      .OnEntry(t => SendEmailToAssignee("you own it."))
      .OnExit(t => SendEmailToAssignee("you're off the hook."));

Implementation needs updating so that self-transitions and ignored 
transitions are handled separately.

Need StateConfiguration.OnExit() overload that supports passing of 
TriggerWithParameters.

Would you consider adding support for guards beyond the simple Func<bool>? I'm 
looking for 

Permit<TGuard>(TTrigger trigger, Func<TGuard> action).
  Transition(TGuard guard, TState destinationState).
  Transition(TGuard otherGuard, TState otherDestinationState).

the chm file will not show any details, only navigation.

Hello.

Currently I'm working on an enterprise level project which has a great level of 
process management, hence stateless. So far, I've been integrating it with no 
problems, but here comes an issue.

We use the MVP pattern in our projects and the state machine is instantiated 
and working in the presenter. The problem is that every time I execute a 'real 
world' action on the process object in the presenter, and if that action 
succeeds, only then I can call a stateless state transition. Otherwise this 
would lead to a state change without anything actually been done on the process 
object itself.

As I noticed, there is no current way of binding any external 'real world' 
actions to the state machine with feedback to the state machine about the 
action execution results. This leads to IMHO unnecessary plumbing code in the 
presenter itself.

What would be your advice on this? Would it be best to modify the stateless 
code to support external actions (i.e. delegates), or create a wrapper with all 
the necessary plumbing and use it instead? What would you do in this situation?

Does this compile in Silverlight 4?
Can you produce an official build?

What steps will reproduce the problem?
1. Clone Stateless project to get fresh copy
2. Open stateless.sln in VS2010
3. Observer that stateless.csproj did not load

What is the expected output? What do you see instead? I Expect the entire 
solution to load; instead stateless.csproj fails


What version of the product are you using? On what operating system? Win7 64 
bit, VS2010SP1


Please provide any additional information below.

Hi,

I've been trying your framework and I like the idea but I've played around 
a bit to allow this:

stateMachine = new StateMachine<State, Trigger, Order>(State.New, this);

stateMachine.Configure(State.New)
    .AllowIf(Trigger.OrderPlaced, State.AwaitingPayment, o => 
o.ReadyToPlace)
    .OnExit(delegate { this.UpdateState(State.AwaitingPayment); });

This allows us to give the entities/aggregates responsibility for deciding 
whether validation is possible (ReadyToPlace). A fluent interface might 
also help, my first attempt was:

stateMachine
    .WhenInState(State.New).Trigger(Trigger.OrderPlaced).CausesTransitionTo
(State.AwaitingPayment)
    .If(o => o.ReadyToPlace)
    .AndResultsInAction(delegate {});

Anyway I was wondering what you thought of this approach and whether you'd 
be interested in taking the project down that path?

Thanks,

Colin

It would be nice to be able to register to an event when a transition is made, 
in order to log the transitions.

Something like in StateMachine.cs: 

    void InternalFire(TTrigger trigger, params object[] args)
    {
        ...
        var source = State;
        TState destination;
        if (triggerBehaviour.ResultsInTransitionFrom(source, args, out destination))
        {
            var transition = new Transition(source, destination, trigger);
            CurrentRepresentation.Exit(transition);
            State = transition.Destination;
            var handler = this.TransitionOccurred;
            if (handler != null)
                handler(this, new TransitionEventArgs(transition));
            CurrentRepresentation.Enter(transition, args);
        }
    }
    public event EventHandler<TransitionEventArgs> TransitionOccurred;

What steps will reproduce the problem?
1. Cannot open the project in VS2010 as it throws the above error

When entry and exit actions depend on other external data, the data may 
need to change between the execution of the exit action of one state, and 
the entry action of another.

E.g.:

    public void Assign(string assignee)
    {
        _machine.Fire(Trigger.Assign, () =>
        {
            _assignee = assignee;
        });
    }

(Here the exit action of the previous state might query the 'old' _assignee 
value, while the entry action of the new state requires the 'new' value.)

However, supporting this will introduce indeterminism in the permitted 
triggers - a transition cannot be chosen until the intermediate action has 
fired.

For this reason it might be worth omitting this capability, as it affects 
few scenarios.

I'm new to stateless and thus am fairly ignorant on a lot of aspects of it's 
use.  This is probably not a bug and by design but it struck me as incorrect as 
far as state machines in general are concerned, but I'm hardly an expert...  

When I do...

SM.Configure (MyStates.Root)
  .OnEntry(() => DoTickFunction())
  .Permit (MyTriggers.Tick);

SM.Configure (MyStates.Child)
   .Substateof(MyStates.Root)

Starting in the .Child state, if you then call

SM.Fire (MyTriggers.Tick);  

the state machine will end up in the root state and not in the child.  I 
would've thought that the purpose of hierarchical states was that a parent 
state could not be transitioned to and that at all times the machine must 
reside in a child state if there is one.  

I see no real advantage to using hierarchical states if a trigger on the parent 
state results in the final state being the parent and not the child.  

But at least now that I understand how stateless works and given that I'm 
making only a relatively small state machine, I can work around what is to me 
at least unintuitive behavior.  

In my situation I have a complex workflow that I want to create once and reuse. 
 During processing I have various objects at different states within the 
workflow.  I want to set the State to the object's current state then Trigger 
it to change states without the need to recreate the entire workflow object.

Here is what I did:

Changed StateMachine.cs lines 16 and 17 to remove readonly.

Added new method:
    public void SetInitialState(TState initialState)
    {
        var reference = new StateReference { State = initialState };
        _stateAccessor = () => reference.State;
        _stateMutator = s => reference.State = s;
    }

Hi,

I've been using "stateless" for the last couple of weeks and I've got to 
say you've done great work here!
There is one issue I'd like to bring up. My state machine consists of a 
hierarchy of states (up to 4 levels deep), where each super-state (a state 
that has one or more sub-states) configures his own sub-states and 
transitions between them on the global state machine (for better design and 
isolation between levels - the root should have knowledge only about the 
1st level states and transitions between them, every 1st level super-state 
should have knowledge only of its direct sub-states of level 2 and the 
transitions between them and so on).
But when a trigger occurs in a level 2 state that needs to trigger a 
transition to a different level 1 state, this transition is based on 
knowledge divided between the root and the level 1 super-state of the state 
where the trigger occurred. This situation requires level 2 trigger to be 
forwarded by the super-state as a level 1 trigger (since the root has no 
knowledge of level 2 triggers).
The solution I found for this situation is to use PermitDynamic with the 
level 2 trigger and in the destinationStateSelector function fire the level 
1 trigger and return the same state (in this case - the super-state), for 
example (int the super-state's code):
SM.Configure(<level 2 state>)
     .PermitDynamic(<level 2 trigger>,
          () => { SM.Fire(<level 1 trigger>); return this; });

This caused a strange bug to appear - I got some calls to functions defined 
in OnExit configurations while being in a totally different states. 
Debugging into the "stateless" code, I've found the problem in the 
InternalFire method. CurrentRepresentation.Exit(transition) on line 185 is 
called even when the transition's source state isn't the current state. I 
simply added "&& this.IsInState(source)" to the "if" statement on line 181 
and the problem was fixed.

I would like to suggest to add a capability for trigger forwarding in a 
more elegant way since (in my opinion) it's a must for good hierarchical 
state machine design over "stateless".

Are there any plans to support shallow & deep history?

To support entry actions on the start state, a different API for starting the 
state machine would need to be provided. The added complexity in classes that 
want to persist state outweighs the benefits of adding this.

Stateless should provide an error when such actions are provided.