StateMachine - A PureMVC / AS3 Utility

[Neil Manuell]

I can see a big value in being able to pass the notification body on to the entering notification, and I can also see that instead of passing the State in the body, we could pass the state name in the notification type...

I'm not totally convinced though

[gjastrab]

Yea, I don't really seen any value in passing the State in the body, but that may just be because I haven't found the need to use it yet.

Why don't you introduce a new class:

StateMachineNotificationBody or something like that?

Code:

public class StateMachineNotificationBody {

  public var body:Object;

  public var state:State;

}

[puremvc]

I agree.

We have to ensure uniqueness on the part of our utilities' notification namespaces.

I think the approach we have is correct, though we could go with a different separator. But we shouldn't have to. It should be able to be anything as long as its unique.

Darshan is trying to imbue more meaning in the notification name than he should.

This is why I wrote Pipes and IPipeMessage. the notification namespace of a module cannot be guaranteed not to overlap with that of other modules, making it impossible to share notifications reliably between cores written by others. Only if you control the entire notification namespace of all modules can that work. Which means nuts to outsourcing big chunks of your app without handholding or opening a platform where others can write modules that plug into your app.

-=Cliff>

[undersound]

Hey.

following this thread, I just want to give my vote on this!!

It would be really great to pass/receive the notification body the one way or the other. I am facing the problem to either define millions of slightly different states or to put some data somewhere more global accessible, both smells bad.

thanks for this library though i really like it a lot!!!

[jon.opus]

Flex apps I have seen define states in the main stage mxml file. If I am in a pure as3 app rather than a flex app where should I define my application states?

[puremvc]

Re passing state, if memory serves, the state you are entering should be in the type param of the exiting note. The state you are exiting should be in the type param of the entering note.

@As for flex states, they are not ther same as application states provided by the StateMachine utility. Flex states are view states, different configurations of view components and their properties which will be used to compose a custom component (not just the main application).

The StateMachine utility provides an application-wide concept of state. It is not mutually exclusive of Flex view states, for instance when the statemachine sends the exiting/entering notifications that make up a transition, mediators for the view could respond by setting the state property of their view components to an appropriate setting for the new application state (not necessarily a 1-to-1 mapping).

But Flex states aren't necessary for use of the StateMachine utility .

To define your application's states, you create an xml description of your FSM (finite state machine. Then from your XML, the FSMInjector creates and injects a fully configured StateMachine into your app.

For more info, check out the article 'Get your FSM On!" In the puremvc.org news section. That will lead you to the utility and the StopWatch demo that defines and implements a simple FSM.
 
-=Cliff>

[Neil Manuell]

The state in flex is specifically a visual state.  The StateMachine utility, manages application wide states.

take a look here http://puremvc.org/pages/demos/AS3/Demo_AS3_Flex_StopWatch/srcview/ to see the Stop watch demo, study the InjectFSMCommand.as (org.puremvc.as3.multicore.demos.flex.stopwatch.controller).  The states are defined in xml, then injected via the FSMInjector into the StateMachine.

[Neil Manuell]

on passing states

@Cliff: the argument here, I think, is not to pass the state in the StateMachine's outgoing notifications, but to be able to pass the body of an incoming ACTION notification onto the outgoing ones, instead of the state.

@undersound: I've come across this problem myself, and my solution was to change the model, then change the state.  I don't necessarily think that data should be passed from one state to another, surely states need have no knowledge of each other.

[jon.opus]

Cliff, I think I understand. I noticed in the Stop Watch Demo that the state names are references to the something like StopWatch.STATE_FOO.

Are you indicating that If I'm not using flex that I should define the state names in the xml? It seams that I would want to be able to Reference them elsewhere in the app. So should I Define those constants in the facade or in a component or the mediator or the Main???

[puremvc]

You can define the constants in your main application class if you'd like, or wherever makes sense to you.

-=Cliff>

[puremvc]

A new version (1.1) of the StateMachine utility has been released for AS3 Standard & MultiCore.

Please read the release notes for details:
http://trac.puremvc.org/Utility_AS3_StateMachine/wiki/ReleaseNotes

-=Cliff>

[Neil Manuell]

cool :)

[Tekool]

Excellent I'm just starting to use the FSM utility. The changelog makes me feel impatient to be on monday.

Waiting for the 'real-world' demo.

[puremvc]

Don't hold your breath on the demo. I'm steaming on a project that you'll all hear much more about very soon. I will be working on something, but spare time is low right now.

For now, read with care the note above and the changes in 1.1 description on the release notes page.

Examine the stopwatch demo for a basic understanding of how to create your FSM and inject it.

In the real world the big difference was I mostly use the 'changed' note for the states instead of the entering and exiting.

I hesitated to put the new version up till I could work out a more realistic demo, but I knew at least on frustrated person recently sunk a lot of cycles into making it do something useful, so I thought I'd be remiss not to post the changes I know for sure work.

Fear not, it is simple but powerful and there'll definitely be more demos and stuff on how to use it forthcoming.

Cheers,
-=Cliff>

[Neil Manuell]

hey, cliff

I like the changes, simple and yet obvious.

Interested to see how this will change the way I use it.