Actually, Cliff, mind if I use this Idea for my Domino project... it's a nice solution for a similar problem I was pondering on...

Hey, nice thinking cliff

from the top of my head, you can get the current state using getViewComponent() on the StateMachine mediator.

For accessing stuff from the State, you 'ld need to subclass it, and add a "get all actions" method.
However, you couldn't use the standard FSMInjector for creating that class, but you could subclass it, or roll you own.

that answer you?

cheers

are you using flex?
have you read the slacker tutorial?
http://puremvc.org/content/view/92/1/

the most likely cause of your problem is the deferred instantiation of the flex component you view wraps

Ah, I took your question to mean why are the StateMachine utils exactly the same between standard and multicore (which they are).

You can get the current state trough the viewComponent property (but you will have to cast it)... mmm doesn't really seem intuitive.
The is no multi core, as there does n't need to be.  You can register a StateMachine in each core, and if necessary you can use the pipes util to communicate between them.

Though I guess a layer of abstraction above these two utils could make the whole easier to use.  Sounds like an interesting project ( I wonder if Fabrication has incorporate something of the like). I'm a bit busy with the FSMVisualiserat the mo - why don't you have a go ;~)

BTW, after my blog being hacked, and my head deep in bread and butter work, I've actually had a bit of time spare to work on the FSMVisualiser, so I might have something more solid to post next week.

cheers

true

The trouble with commands modding the notification is that it means that the command becomes 'aware' of its context.

agreed, and you can also add that any code must have some awareness of its environment, but no more than necessary.

The command "knows" the framework, the command is there to do a certain job on a certain object - even if that object is hiding behind an interface, it must know that interface. It must know how to obtain it, whether from the notification body, or retrieving it from the framework.

so what is the difference between passing a proxy name in the body, or an array of proxy names, the command is expecting one or the other or either.

your command could type check the note body, use a string or pop from an array, or an array collection, or a linked list, or whatever. It could even take a leaf from "Chain of Responsibility", and if it can't do its job in the environment it was expecting, it pass the job on to the next command, which may be able to.

what is the difference between passing an array of proxy names in a notification, which is modified by a command and passing a proxy in a notification which is modified by a command? or are you saying that to pass an object in a notification to a macrocommand is to tightly couple its subcommands?  I'm not sure about this.  Also, if any tight-couplings are to appear in your application where better that in your commands, which tend to be (though not exclusively) tightly coupled to the application in which they are implemented.

Well, for the basic pureMVC, I think the solid, simple way is best... and there is always a fairly simple solution for most problems ( and don't for get that commands can modify just the notification if needed ).

However, as an additional "bolt on" utility that builds on the basic, I think that this is a grand idea... over to you Will...

(oooh, and while your there, I've also also like the idea of being able to inject subcommands at run time too... that would be awesome! )

try sending an array of your proxynames as the body of the notification, then each command can pop them off...

More functionality to the FSMVisualisation (we need a name, any suggestions?).
http://revisual.co.uk/?p=517

@Cliff Yes, nutty hard, haven't fond a way to label them actions, but surely there will be. Am thinking of a rollover info box that will show all the info.

functionality now includes adding/deleting states adding/deleting actions.  Very crude at the mo, will whip up something more appealing when I have done more functionality.

@cliff, I have added the entering guard code in to the svn

have stuck a demo visualisation of the FSM Markup Utiliy I have been working on here:http://revisual.co.uk/?p=501.

yep, thats right

Just starting a new project, so I'm going to try these potential changes out, see what comes out.
will let you know.

is this what you were thinking:

:

protected function transitionTo( nextState:State, data:Object=null ):void
{
// Going nowhere?
if ( nextState == null ) return;

// Clear the cancel flag
canceled = false;

// send exiting notification for the current State
if ( currentState && currentState.exiting ) sendNotification( currentState.exiting, data, nextState.name );

// Check to see whether the exiting guard has been canceled
if ( canceled ) {
canceled = false;
return;
}

// send entering notification for the next State
if ( nextState.entering ) sendNotification( nextState.entering, data );

// Check to see whether the entering guard has been canceled
if ( canceled ) {
canceled = false;
return;
}

// only change state nownow
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 );

}