Links:
http://code.google.com/p/sg-camo
http://code.google.com/p/fakemvc/
SG-Camo ( http://code.google.com/p/sg-camo ) , has been updated with some slight updates and fixes, including a new FakeMVC framework branch under sg.camo.fakemvc which houses a state machine similar to PureMVC, but with far more features to help support rapid flash development, whether on the small or large scale. PureMVC’s basic finite state machine can be found at http://puremvc.org/content/view/104/1/.
For one thing, the difference with SG-Camo+FakeMVC’s approach is (i feel) it can possibly allow for a more versatile Site Model creation/navigation structure design through nested node states support (similar to Gaia Flash framework with it’s page within page support), but without the hard-coded nature of specific node types prescribed by Gaia’s page and asset methology.
In FakeMVC’s state machine, you define any number of nodes (as many levels deep as you wish) to either represent states or action-based transitions, and the standard attributes that go along various state nodes via CSS selectors, especially defining what exiting/entering notifications occur through the facade when you exit/enter such nodes accordingly within your typical site transitional flow. The flow can be hijacked, lock, and released at anytime similar to Gaia through a NodeStateCommand reference which is also provided by the handler method with the TransitionNodeEvent passed in. So, you basically define your own custom handlers in your site mediators (and other facade listeners) to determine how such states are being processed accordingly. Additionally, there are handy attributes like “inherit” (to allow transitions from parent levels to be triggerable) and “enterState” (to constantly drill into nested states step-by-step), including the ability to setup presetted nested xml-based chunks for certain xml node types, allowing you to truly generate your SiteModel (ie. templating) and define your site flow from the ground up, and rapidly too.
Like PureMVC’s state machine, each xml node dispatches their own entering/exiting notifications via inline attributes and accompanying CSS definitions, which are all powered by Flash camouflage property application/mapping system. Also, entering/exiting notification attributes can be stacked (they don’t get overwritten), allowing multiple notifications to be dispatched out per node, and so your various selectors (it’s node, class id selector, and inline node attribute specifications), is pretty much self-sufficient to get whatever functionality you require for your various states. As an added bonus, this is run over the classic XMLNode’s DOM (Document Object Model) which stores a generic “attributes” Object, therefore allowing your xml nodes to immediately house serialized data within the state nodes itself beyond Strings. The framework therefore also allows you to optionally define your own custom node types and proxies which can also help in storing actual runtime content (or just serialized data types) in the xml node DOM-based attributes themselves through Flash’s camouflage’s property mapping system. In short, you can allow certain node types (and their accompanying intended attributes) to be documented and referenced from extended NodeProxy classes, preventing the need to write messy inline code to re-process/cast raw xml string data each time you reference those xml nodes again. By creating NodeProxy-based classes with exposed public strictly-typed variables and setters, this would allow Flash Camouflage to map those properties accordingly to their respective data types into the xml node’s attribute object, allowing data to be automatically serialized from the beginning. Even automatic Number(), Boolean(), and int() serialization can come in useful in such circumstances. Thanks to Flash Camouflage property selector/mapping utilties, setting this up was a real snap.
Honestly, I haven’t touched much on PureMVC in general, and FakeMVC was simply made as a simpler (and more raw, single-core alternative) to PureMVC. So, it’s rather incomplete/imperfect as usual. But think of it as a mixture of Gaia and PureMVC’s StateMachine on steroids.
The core files for FakeMVC is at org.gxero.fakemvc under http://code.google.com/p/fakemvc/ .
The entire SG Camo framework (with it’s FakeMVC State Machine branch) can be found at http://code.google.com/p/sg-camo .
Here’s a sample of a xml file:
<?xml version="1.0" encoding="UTF-8"?>
<FakeMVC>
<!-- FakeMVC/NodeStateCommand is still in development and this is just a mock SiteModel xml which isn't tested. You are advised to start with a simple one and test out FakeMVC's features accordingly with it's current in-development code-base -->
<SiteModel gotoState="/index/landing">
<!-- App section -->
<Index id="index" enterState="landing">
<transition name="next" notify="goNext" />
<transition name="prev" notify="goPrev" />
<page id="landing" inherit="1">
<transition name="jumpToGame" target="game" />
</page>
<page id="game" inherit="1">
<transition name="game1" target="./createGame/game1" />
<transition name="game2" target="./createGame/game2" />
<transition name="game3" target="./createGame/game3" />
<transition name="game4" target="./createGame/game4" />
<game id="createGame" >
<transition name="gotoLanding" target="/index/landing/view" />
<transition name="gotoResults" target="/index/results/view" />
<scene id="game1" />
<scene id="game2" />
<scene id="game3" />
<scene id="game4" />
</game>
</page>
<page id="results" inherit="1" />
<page id="submitForm" inherit="1" />
<page id="thankYou" />
<page id="taf" inherit="1" />
<page id="thankyou">
<transition name="returnHome" target="/index/home" />
</page>
</Index>
<page id="viewLeaderboard" />
</SiteModel>
<SiteModelling>
<!-- define default extra attribute properties for various nodes with CSS selectors to be combined with the SiteModel's inline node attributes.. -->
<!-- -->
<!-- define 'inherit' for state nodes in order to also inherit <transition> actions up the site tree based on the number of times specified. default is zero -->
<!-- -->
<!-- Any node with a 'name' attribute found is treated as a <transition> action at the moment. This is triggerable through NodeStateCommand.runTransition() -->
<!-- -->
<!-- Any node with an 'id' attribute is treated as a <state> node at the moment. -->
<!-- -->
<!-- Entering/exiting attribute properties are used to define the notifications being sent out when the NodeStateCommand travels in/out of those nodes -->
<!-- -->
<!-- Entering/exiting attribute setters are stackable (so your node states can dispatch multiple entering/exiting notifications). If you need to declare overwrites, use the '_entering' '_exiting' properties with underscore prefix -->
<!-- -->
<!-- All transition target paths being used are relative from the current state position. ./ will drill into the tree 1 time. "../" drills out accordingly by the no. of times. "/" prefix uses absolute global path. And no slash prefix indicates current level navigation. -->
<!-- -->
<!-- Transition nodes also contain an optional 'notify' attribute to send out a single notification when it's being successfully called. If no 'target' is specified, no transitioning will occur as well. -->
<!-- -->
<!-- The 'enterState' property is used to automatically drill into a nested state when the node is reached at the end of the transition. If the enterState node also has another "enterState" value, the process repeats as long as the value is different from the previous one. In this example, navigating to a page node will drill into the nested "view" node state automatically before the whole transition is deemed finish -->
<!-- -->
<!-- At any time, the flow can be paused with NodeStateCommand.hijack() and resumed with NodeStateCommand.release(). You can specific a lock true parameter in the hijack() function if you wish to lock the command and prevent anything from occuring till you release it. Flows can be interupted and redirect to new destinations. -->
<!-- -->
<!-- TransitionNodeEvent is used as the event being passed to the event handler for such facade notifications. It includes the 'node' property which references the current XMLNode, and the 'command' property which references the currently triggered NodeStateCommand, allowing you to hijack/change/resume the flow within the handler context easily. -->
<Properties> <![CDATA[
page {
entering: onEnterPage;
exiting: onExitPage;
enterState: view;
}
view {
inherit: 1;
}
#view {
entering: onView;
}
#viewLeaderboard {
entering: onViewScores;
}
game {
entering: onEnterGame;
exiting: onExitGame;
}
scene {
entering: enterScene;
exiting: exitScene;
inherit: all;
}
load {
entering: doLoadAsset;
exiting: onLoadAssetDone;
}
runGame {
entering: doRunGame;
}
]]>
</Properties>
<!-- define any default nested state nodes to exist in certain node types -->
<NestedNodes>
<page>
<view id="view" />
</page>
</NestedNodes>
</SiteModelling>
</FakeMVC>