Aug 14, 2008 at 6:46 PM
I have been using the simple state machine for a few months now. It has proven to be exactly as described. Thanks for this. Since using it the only thing that seems to be needed is being able to invoke tasks when an event has fired, not just when state enters or exits. Would anyone agree? Or did I miss something along the way (quite possible).
Aug 15, 2008 at 1:31 AM
What is your use case? I don't have a theoretical problem adding this, but I'm curious what is the reason?
Aug 15, 2008 at 1:55 PM
So, let me first preface that nothing has prevented the job from getting done that needed to get done. My suggestion is more conceptual than a need (so maybe a bad choice of words when I said seems to be needed), because personally I like to talk about some things as part of the model (model meaning state machine in this case). If we take the sample Order.boo work flow included in the solution and the business says they want to send an apology to every customer when an order is lost. I think expressing that request in the work flow model is both conceptually useful, and minimizes code noise to accomplish the task.

state @InTransit:
    when @OrderReceived     >> @OrderComplete
    when @OrderLost            >> @AwaitingShipment
        on_event_fired @SendApologyToCustomer

or alternatively...

trigger @OrderLost:
    when_occurs @SendApologyToCustomer
Feb 12, 2009 at 11:38 PM
i am trying out simplestatemachine and have encountered the same issue as katokay. what's your workaround the issue katokay?


Feb 14, 2009 at 9:19 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Feb 15, 2009 at 3:52 AM
Better late than never, hopefully :) I just checked in support for this feature. I adopted both styles, so you can add event actions to the state machine as a whole, which means that any time that event is received at any time during the life of the state machine the defined task will be executed, or you can add an even action to a specific state, which limits the scope of the action to events received while in the specified state.

#Event Definitions

trigger @OrderPlaced
trigger @CreditCardApproved
trigger @CreditCardDenied
trigger @OrderCancelledByCustomer
trigger @OutOfStock
trigger @OrderStocked
trigger @OrderShipped
trigger @OrderReceived
trigger @OrderLost:
on_event @WriteToHistory, "Order Lost event occured. Oh No! Sorry Mr. Customer!"


state @AwaitingPayment:
when @CreditCardApproved       >> @AwaitingShipment
when @CreditCardDenied         >> @OrderCancelled
when @OrderCancelledByCustomer >> @OrderCancelled
on_event @WriteToHistory, "The order was cancelled prior to payment. Probably accidentally clicked 'One Click Checkout'"

Feb 15, 2009 at 11:26 PM
thanks heaps.

Feb 16, 2009 at 4:48 PM
I was doing my usual checks to see if anything new had happened with this project and saw this. Looking forward to this change. Very much appreciated!
Feb 17, 2009 at 4:43 AM
No problem - let me know if it gives you any trouble.
Feb 17, 2009 at 2:10 PM
The feature works well - I've incorporated this to our soon to be production system - we chose this library over WF. Good work.