so a change of conception in my head, not necessarily in the code.

will need to think about this.

OK, cool...
lets say I've navigated the exit guard of a state successfully, and done my teardown.  However the next state's entry guard has forbidden entry. So I am still in the previous state, but I have already torn it down...
how do I overcome this?

no, thats not right, because with your description, on cancellation of a transition, the entered phase will NOT be reinvoked.  OK, I go with the non reinvoking of the entering phase, but if a state's exiting phase has been invoked, its entered phase must be reinvoked if cancelled. Otherwise you can't maintain the state's proper environment

am i making sense?

well, I guess it depends how you define these things.

I would say that if you are going from the hallway into the office you leave the hallway, and enter the office by passing through the doorway. And the doorway is neither in the hallway, nor is it in the room, it is the place that connects them (though I agree that in a synchronous system this transition phase has much less value than in an asynchronous one).

The way I have seen the entering phase is as a preparation phase. You use it to prepare the correct environment for that state, and while its being prepared, you arn't in that state, because its not fully prepared. The entered note indicates this. The exiting state is the same but in reverse. As soon as you start de-preping that state it is no longer in that state, but in a dismantling phase.

As you go through the doorway, you switch the light off in the hallway, then you switch on the light in the office, and walk in (ok, maybe not always in that order but lets stick with it).

It seems that the only use for the entering and exit notes in your suggestion are as a hooks  to allow cancellation of the transition. You can no longer, for example use the entering phase to say, disable interaction, and turn it back on on the exiting, because if the next state's entering phase cancels the transition, the user interaction is not switched off again, breaking state's environmental safety, which is surely the whole point of having a FSM.

Looking again at this, I see that it is the entering phase that can be used only as a cancellation hook. The preparation of the state can be done in the changed note. So you can check whether the conditions are right on entering, when you hit the changed note, disable user interaction, and do what is to de done in that state, then on exiting enable interaction again.  If the next state cancels the transition, the preparation is done on the entered, so the states environment is not compromised.  

OK

So thats alright then.

(though I think that
a) the names of the states are no longer quite as descriptive and
b) it would need good documentation of the phases and the consequences of cancelling in the wrong places.)

like this?

:

protected function transitionTo( nextState:State, data:Object=null ):void
        {
            // Going nowhere?
            if ( nextState == null ) return;
           
            // Clear the cancel flag
            canceled = false;
               
            // Exit the current State
            if ( currentState && currentState.exiting ) sendNotification( currentState.exiting, data, nextState.name );
           
            // Check to see whether the transition has been cancelled in the exiting state
            if ( canceled ) {
                canceled = false;
                return;
            }
           
            // Enter the next State
            if ( nextState.entering ) sendNotification( nextState.entering, data );

           // Check to see whether the transition has been cancelled in the entering state
            if ( canceled ) {
                canceled = false;
                 if ( currentState.entering ) sendNotification( currentState.entering, data );
            }else{
                 currentState = nextState;
            }
       
            // Send the notification configured to be sent when this specific state becomes current
            if ( currentState.changed ) sendNotification( currentState.changed, data );

            // Notify the app generally that the state changed and what the new state is
            sendNotification( CHANGED, currentState, currentState.name );
       
        }


yes, that sounds good.
I have stopped using the entering notification for a state in favour of the entered one in 1.1, simply because it has no more value, and actually "lies" about the current state.

Cancelling a transition in the entering state would give it its power back, because I think that its job is a very different one than the entered.

so if you cancel an entry note, the state will revert back to the previous state, and trigger its entering state again (as its state's exiting note will have been sent. )

And if no cancellation is made, there will still be that little lie about the current state. What do you think of a neutral state (that holds previous and next state) to cover the small period between exiting the old state and before entering the new?

just a thought...

If the StateMachine is queried reguarding the current state during an entering notification, it will return the previous state.

I was wondering if there should be a neutral StateTransitionState, so the transitionTo method would read
something like.

I'm not sure if this would make any major practicle difference but it would be slightly more "truthful".

:


{
            // Going nowhere?
            if ( nextState == null ) return;
           
            // Clear the cancel flag
            canceled = false;
               
            // Exit the current State
            if ( currentState && currentState.exiting ) sendNotification( currentState.exiting, data, nextState.name );
           
            // Check to see whether the transition has been canceled
            if ( canceled ) {
                canceled = false;
                return;
            }

            // makes currentState into a neutral State
            currentState  = new StateTransitionState();

            // Enter the next State
            if ( nextState.entering ) sendNotification( nextState.entering, data );
            currentState = nextState;
           
            // Send the notification configured to be sent when this specific state becomes current
            if ( nextState.changed ) sendNotification( currentState.changed, data );

            // Notify the app generally that the state changed and what the new state is
            sendNotification( CHANGED, currentState, currentState.name );
       
        }


re: state layout "middle-ware" application
just to say I have finally got round to looking at the flare framework, and it seems pretty straightforward to use (once I got my head around it).
so I might start throwing up some tests (when I find the time).

unfortunate turn of phrase... maybe "throwing out" would have been better.

Well, as i said, Domino is an experiment at the moment... and one that I have had to put aside at the moment, so I can pay my mortgage :/.

The idea is that it "plugsin" to the StateMachine, and allows a non-linear chain of commands to be executed that is determined by an externally loaded model.

The prototype that I have up and working works well, but its integration with the StateMachine is clumsy (I think cliff's latest changes to the StateMachine will solve these problems when I have a chance to go back to it).  The problem as a whole is that I think it really needs a visual programming type of interface. So its either a massive project, or its pointless.

Also, I think that a visual markup tool for creating the StateMachine definitions (as cliff has suggested had he the time) would be a far more worthwhile and helpful tool in the short term. So I am going to attempt that first. It would also be a good starting block for domino should I continue.

I think that cliff's suggestion, splitting your application into smaller, more manageable modules, each with their own StateMachine is the way to go.

So I guess a StateMachine markup tool needs to build multi-core StateMachine definitions too.

have had a quick look at fuse.
will have a more in depth look when I have some time to myself.. which should be in a few weeks

this seems to be a question that is asked a lot...
is it possible to pin your last answer up somewhere?? a FAQ page??

@ cliff

I want to build a middleware tool for creating, visualising and testing the fsm definition.

If you wanna farm some code of that out, Id be happy to help...

Yep, thats what I found when I tried to implement a Asynchronous StateMachine transition using the Mcdaddy: http://revisual.co.uk/?cat=61

I'll see if I can update those demos for the latest build...

though, they might not be more useful than they are at the present

Yes, I've found myself making hacky workarounds
am about to start a new project and will def be using it in that