StateMachine - A PureMVC / AS3 Utility

[puremvc]

A nice demo for sure, but I thought we were looking for a demo of StateMachine in conjunction with AsyncCommand?

-=Cliff>

[Neil Manuell]

LOL, yes, that's next on my list.... I wanted to show two ways, encapsulating the asynchronisity in its own state, and an asynchronous state transition.

Its just that the project I ripped the demo code out of handles it the former way.

I will try to do it by the end of the week.

[Neil Manuell]

well here it is:

http://revisual.co.uk/?p=409

The AsynchMacroCommand doesn't seem the keep the thread, and so the DISPLAY state is entered before the load is completed ( check out the enabling of the button states ). This is ok in the demo, as the progress window is modal, so restricts interaction. So using this method requires more care.

Have a look and see if I've done something wrong...

cheers

[GroundZero]

This is a very nice edition so let me start by saying thanks to those involved with getting this put together.

In the last 6 months I have become very attached to the Fabrication code base that can be used to eliminate much of the need to write "glue" code in the mediators etcetera.  The State Machine is not exactly playing nice with this stuff and I really do not want to have to make a decision as to using one or the other (pureMVC+Statemachine as opposed to PureMVC+Fabrication).  Yes, I know, I want to have my cake and eat it too..then ride a rollercoaster and maybe go for a nice skateboard ride

The issue arises when you are trying to write your notification handlers in the mediator for your application.    With Fabrication, you don't need to use listNotificationInterests....you jsut write the handler out prefixed with "respondTo".

So a note called "userModelChanged" could be easily picked up in the mediator by writing up a function named "respondToUserModelChanged" and BAM you are off to the races.

Unfortunately the State Machine "changed" note name contains forward slashes and prevents us from using Fabrication.  I thought for a moment maybe I could just handle the state changed using "pure" pureMVC listNotificationInterests methods.   But Fabrication sees this and will not respond to other "respondTo" methods.

I REALLY wanted to continue usage of Fabrication along with this State Machine so I dug in and altered the Static constant for the "changed" name to be "stateChanged" instead of "StateMachine/states/changed".

This seemed to have no impact on the way the state machine operates and allowed me to write my "respondToStateChanged" and my originally needed "respondToUserProxy" handlers so Fabrication can do its awesome magic.

Of course I am now forced to use the uncompiled source, but hey!  It works!

 I have converted the StopWatch example to use Fabrication on top of pureMVC and the State Machine.
For some reason I also had to register the commands for them to execute. Could someone explain how the slash notation in the currentState.name is really meant to be used? I see other constants in the example using this notation and just wanted to be more clear about the impact of my own changes.

Thanks again!

[gjastrab]

Wouldn't this be an issue to take up w/ the Fabrication utility and not StateMachine?  What if someone uses the convention of putting slashes in their constants out of preference (I have begun doing this for all of my Facade constants).

I haven't used Fabrication yet, so I'm not sure how that works, but it seem that Fabrication should perhaps detect and trim out bad characters, replacing them with empty space, or underscores or something when trying to call respondTo*...

[GroundZero]

Yes I have had these thoughts too.  Underscores were my first choice.  I am going to talk to Darshan about it to see what he thinks. Until then I will work on the Fabrication sources as well to see what I can come up with.

Please understand that I was not taking issue with anything or saying it is a bad choice made, but merely pointing it out for the folks on these forums that are using Fabrication and may be running into issues.

[gjastrab]

Of course, I wasn't criticizing your post, but just suggesting that the problem should be addressed at the root cause in order to prevent the same thing from occurring elsewhere (people using slashes in their constants), rather than changing the way state machine names its constants.

[Neil Manuell]

hi GroundZero,

you have brought to a point a question that I have been asking my self.  There is a lot of really great stuff  coming out around the pureMVC frame work: fabrication, pureMVC Studio, and I'm not sure whether they will be compatible with each other. I'm working on my own little project, and don't want to create something that can't be used seemlessly alongside the like.  

In this case though, I have to agree with gjastrab, I think using package conventions on note names is a really useful way to avoid pollution, and they are simply Strings, and should be able to contain anything. I think you are right about talking to Darshan about this, as the fact that they can't work together needs to be ironed out. I'd be interested to hear Cliffs views on this.  I'm sure he has a master plan that he hasn't divulged to us yet.

[GroundZero]

Yes, I agree some "regex" magic is needed to remedy this in the Fabrication package.  I want to use the state machine in a project I am doing now (that has a 30 day deadline) so went the route of a "quick fix" by just removing slashes in the event name. I see the point about pollution of notes/events.  I guess this is similar to the "addressing" of modules in a pipes application (I have done 2 now and will never go back to the single instance packages!).  I am going to go post on code drunks so both parties are aware.

Thanks for such prompt replies!

[Jason MacDonald]

Fabrication already uses a slash syntax for note names behind the scenes because module instances share the same note names. Both ModuleA_Instance1 and ModuleA_Instance2 have the same notification interests because they are both instances of ModuleA . Routing needs a way to send a route to moduleInstance1, and not moduleInstance2 of the same module (this is the entire point of Fabrication, simplifying communication between modules and allowing finite communications.) It accomplishes this by changing the noteName internally to a path like "module/instance/noteName" rather than just "noteName", and then stripps away the path from the note name when it's time to call the actual function held under that path. If you were to name a note with slashes, it would end up looking like "module/instance/note/name/too/many/slashes" and would fail to properly trigger the associated method when the module/instance part was strip off.  It would try calling respondToNote/name/too/many/slashes() which is note a valid function name.

Asking a developer with a huge code base, who's project has existed much longer than this one, to change his entire logic of routing to work with a very small utility seems a poor choice of fixes to me. I for one would much rather roll my own StateMachine without slashes than try to rewrite all that Fabrication does. Not using slashes in  note names is a small trade-off for the power fabrication gives me.

Just my two cents, but I hope Darshan does not change his routing logic.

EDIT: Changed first paragraph to better explain routing paths and why they are used as note names.

[gjastrab]

Hm, that does complicate things if it relies on interpreting meaning from slashes in a notification name in Fabrication.

I think fleecie's right and now that the PureMVC community/tools are growing it's going to be interesting and important to see how to better tie things together to ensure they play nicely.

+1 on being interested to see if Cliff has anything cooking in this area yet...

[Neil Manuell]

sure, jasonmac, I bow to your knowledge of Fabrication, I haven't had a chance to look at it yet.
If it's entire notification system relies on slashes, then:

Asking a developer with a huge code base, who's project has existed much longer than this one, to change his entire logic of routing to work with a very small utility seems a poor choice of fixes to me

seems a sensible attitude :~)

The slash notifications in the State Machine were added by Cliff, so I await his judgement.

as I said previously, I think this is going to happen more and more, and not just for simple utilities like this one. 

[GroundZero]

I dug around a bit and saw this as well Jason. Thanks so much for your post  . It made me feel a bit better about my quick fix. Maybe it IS the best thing to do for now...I like the routing when using pipes/fab the way it is as well.  I was afraid however that for some reason unknown to myself, that removing the slashes would break something in its core functionality. This is not the case, WHEW! I am so glad these forums exist.

[Neil Manuell]

btw, i always used to use . delimitation with my note names which, of course, would not clash with the Fabrication /
just a thought
:~)

[Jason MacDonald]

I can almost 100% guarantee the reason Cliff added the path was because note names like "change" are far to generic and likely to be used by other people in their own apps. By using the static name of stateMachine, along with the "path", he guarantees there won't be a clash of names at run-time. However the same can be accomplished using "stateMachineChange", "stateMachineNotesChange" or even "stateMachine_notes_change" instead of "StateMachine/notes/change".

The "/" in this case serves no real purpose other than to provide a unique name. There's no demand, in the case of a "pure" puremvc app, for there to be a path in the note name.