that would be cool

Hey cliff,

surely if you use the AsynchMacroCommand, on an exit Notification, as soon as the executing code hits an AsynchCommand (and added a handler), it will continue back down the call stack, to the StateMachine, and send the enter notification for the next state, then run any code registered for it, and only when the entire thread has completed, will it be able to execute the handler for the exiting AsynchCommand, allowing the AsynchMacroCommand to continue.

I'm by no means an expert on the execution order of AS3 code, but the above was my understanding of it.  I also have to admit that I haven't actually tried it, as I didn't think it would work :~/

mmmm this is quite a pertinent question, as it involves an asynch element.

The fact that the StateMachine Util is itself synchronous, must be taken into account. The important thing is not to fire an async command from the exiting notification of a State (and I see no reason why this should be needed, these should merely provide 'clean up' functionality).  It is likely that this will mean that the enter Notification of the next state is fired before the asynch process of the exiting State has finished.  The Synchronous nature of the StateMachine can be worked with by encapsulating asynch processes into separate states.

These are two methods that I have employed myself:

             MainState
              |        ^
   (loadAssets) (loadComplete)
              V        |
             LoadState

or

             MainState
               |      ^
   (loadAssets) (loadError)
               V      |
            LoadState
                 |
         (loadComplete)
                 V
           DisplayState

This also allows restriction of user activity within the loading state, and ensures that a view can be bound to it (ie a prog bar).

hope that helps :~)

i think that its definitely worth documenting as a way of extending the utility... that gives the user a choice

by the way, how would you ensure that the state classes get compiled?
if you are typing to interfaces and defining class paths as strings, there is no guaranteeing that they will.

I usually wrap my getDefinitionByName method in a factory that explicitly declares all the classes to be compiled for that factory, then pass the factory where it is needed.

However, this is just another class, another piece of tramp data, and another complication...

oh, and merry xmas

I agree with cliff that the namespace option is, lets say a little specialised, for general use... I think it may scare off quite a few people.  The verbose declaration is simple and obvious, though not as elegant, though I may have a play with this idea.

sorry, had a server error this is the whole post


actually want to extend the nextCommand()   thus:

override protected function nextCommand():void{
    var note:INext = notification as INext;
    var nextClass:Class = note.getNext()
    if (nextClass != null)   addSubCommand(nextClass)
    super.nextCommand();

}

In this way the subcommands would be created dynamically instead of through the initializeCommand() method.  I completely see that this is a very specialised and unique case that doesn't really warrant a change.  It would just be a nicer to extend the AsychCommand Utility from a swc than create "parallel" code

cheers

I thought you might say something like that

hey hold on your right! looking at it again, i see that I've made a huge error... I actually want to extend the nextCommand()   thus:

 override protected function nextCommand():void{
var note:INext;
         note = notification as INext
         addSubCommand(note.getNext())

so I can do this:

override protected function onCommandEnter( notification:INotification ):void{
   var note:INext;
   note = notification as INext
   addSubCommand(note.getNext())
}

better make it onCommandEnter( notification )

feature request:

mmm I really want a pre nextCommand hook:


public final function execute( notification:INotification ) : void{
    note = notification;
    onCommandEnter()
    nextCommand();
}

protected onCommandEnter():void{}

any chance??

cool, let us know of any problems / solutions / additions that may pop up

also it is very light weight, and there is nothing in there that does not need to be, it has also been created with extensibility in mind.
if you write your own one, more than likely it will be squewed by the project for which it was written. And will always need to be adjusted, refactored for each new project that comes up.

also, the work is already done why do it again, especially when you have such a community around it to kick ideas around in...

thanxs

and also having some kind of a stateVo to store a few configs in.

well, there already is a stateVO that you can subclass.

Its interesting that what I have read here so far, is that states seem to be very much linked with the view (including in the flex framework).  I tend to see it as more general than that.  I have a "bootstrap" state that manages the start up; or a "save" state that manages saving out data; or an "edit" state that switches the view state...

hey, just come across the finite state machine discussion group :~/

wondering where my little util comes in to the wider view.
obviously its a very simple lightweight implementation.

also, perhaps I should subclass and add some state history?