Thanks Cliff!
I've seen examples of video players refactoring the Netstream creation and configuration into a proxy-model , and I've tried to do something similar but it really seemed counter-intuitive, as well as adding an unnecessary layer of complexity. Most importantly it also seemed to go against one of the primary goals of MVC, maintaining true portability and independence of the view components.
However, I think a videoplayer is a great example of an application that would make great use of the State pattern, and will definitely try to incorporate the FSM.

I'll reserve proxy use for cases where I'm loading an xml or external playlist.

Thanks Mirux, appreciate the reply but wasn't asking for an overview of PureMVC.

My question is about architecting a PureMVC Video Player, especially the role of a proxy-model outside of say, parsing a video playlist.

Should there be a separate 'NetstreamProxy', and if so, can someone list any specific advantages of why it would make sense to refactor the NetStream related code into its own class?

Thanks I'll try that. I was referencing the Stopwatch demo that doesn't use Changed Notification name constants.
I was under the impression that StateMachine.CHANGED notifications were always sent, and you weren't required to explicitly include them in your definition.

And that mapping the StateMachine.ACTION  actions to commands was a best practice when making changes to your proxy.

Examining the definition in the SOA example I can see how important naming your constants becomes, though 'STOPPED' or 'STATE_STOPPED' seem a lot more intuitive as state names than 'STOPPING', and using NO suffix makes more sense in describing ACTION. To simplify even further, I would drop the 'ING' suffix altogether and simply use the 'ED' suffix for both state names and CHANGED constants, or use 'ING' for both names and CHANGED constants when it makes sense, ie PLAYING. In any case, you are simplifying constant use, repurposing one and using 2 instead of 3.

Statemachine Definition Constants

ACTION (should end in 'ED' ie STARTED)- notifications sent TO StateMachine
CHANGED (should have no suffix ie START)- notifications sent FROM StateMachine
NAME (should end in 'ING' ie STARTING) - actual state names used internally by StateMachine

my revised suggested naming scheme

ACTION (should have no suffix ie START)- notifications sent TO StateMachine
CHANGED (should end in either 'ED' ie STARTED or 'ING' ie STARTING )- notifications sent FROM StateMachine
NAME (should end in either 'ED' ie STARTED or 'ING' ie STARTING) - actual state names used internally by StateMachine


So my suggested much simplified definition becomes the following. The only departure from my suggested scheme is that I am using a RESET action to get to a 'READY' state , and I can probably further simplify by eliminating 'RESUME' and simply use 'PLAY' instead. I've also eliminated a 'STOPPED' state, since it was essentially the same as a 'PAUSED' state.

//CODE START
<fsm initial={Main.READY} >
            <state name={Main.READY} changed={Main.READY}>
                <transition action={Main.PLAY} target={Main.PLAYING}/>
            </state>
            <state name={Main.PLAYING} changed={Main.PLAYING}>
                <transition action={Main.PAUSE} target={Main.PAUSED}/>
                <transition action={Main.RESET} target={Main.READY}/>
            </state>
            <state name={Main.PAUSED} changed={Main.PAUSED} >
                <transition action={Main.RESUME} target={Main.PLAYING}/>
                              <transition action={Main.RESET} target={Main.READY}/>
            </state>
            
         </fsm>;
//CODE END

This is what I have so far, unless I'm mistaken I don't see the need for any entering or exiting guards.
Can anyone suggest whether I'm on the right track?

//CODE START
<fsm initial={Main.STATE_READY}>
            <state name={Main.STATE_READY}  >
                <transition action={Main.ACTION_START} target={Main.STATE_PLAYING}/>
            </state>
            <state name={Main.STATE_PLAYING} >
                <transition action={Main.ACTION_PAUSE} target={Main.STATE_PAUSED}/>
                <transition action={Main.ACTION_STOP}  target={Main.STATE_STOPPED}/>
            </state>
            <state name={Main.STATE_PAUSED} >
                <transition action={Main.ACTION_RESUME} target={Main.STATE_PLAYING}/>
            </state>
            <state name={Main.STATE_STOPPED}>
                <transition action={Main.ACTION_RESET} target={Main.STATE_READY}/>
            </state>
         </fsm>;

//CODE END


and then in my ApplicationFacade

//CODE START
override protected function initializeController () : void
      {
         super.initializeController();
         registerCommand( STARTUP,       StartupCommand );   
registerCommand( Main.ACTION_RESET,       ReadyCommand );
registerCommand( Main.ACTION_START,       PlayCommand );
registerCommand(  Main.ACTION_STOP,       StopCommand );
registerCommand(  Main.ACTION_PAUSE,       PauseCommand );
registerCommand(  Main.ACTION_RESUME,       PlayCommand );
}
//CODE END

For my next project I'd like to create a modular video player using puremvc.

Obviously a case for Final State Machine, but confused about proxies and mediators.

What should the function of a proxy be (in a videoplayer)?

ok thanks Cliff.
As I understand it one of the goals of the FSM is to decouple view component state management (VISUAL) from overall application state (BEHAVIOURAL ) management using Mediator logic to determining what to change in the associated visual component.

A mediator could listen to a 'CHANGED' event to swap out a graphic or somehow change the component.

But I'm still not clear if it would make sense to describe each sequential step in my application as 'states'. My guess is NO, since as I understand it, states should describe global properties or conditions of the entire application. And the only 2 global conditions of my application are 'LOGGED IN' and 'LOGGED OUT'.

....just trying to figure out the best way to integrate FSM into my PureMVC project without complicating things

I've built an application that has a number of sequentially viewed steps (my view components) and also also allows the user to be either 'loggedIN' or  loggedOUT'  while navigating from step to step.

Chapter 10 of the excellent 'HeadFirst DesignPatterns' describes the State Pattern as 'encapsulating state-based behaviour and delegate behaviour to the current state'

I'm thinking that being 'logged IN' or 'logged OUT' represent 2 discreet states and perhaps I should be implementing the state pattern (ie the FinalStateMachine) BUT,  the behaviour of my application doesn't change on logged IN or OUT, only the appearance changes.

Can anyone share their rationale and or examples in using the State machine and-or help clarify the above?

Hi
Could someone describe examples of when it would make sense to use Multicore over single core?

Having just completed my first large commercial project a few things I've learned
If you have many similar view components, make sure you program to interfaces
Use macro commands whenever possible
For a large application more time spent in the planning stage pays off later
-ie list all core actors, proxies, commands, mediators and their responsibilities
-establish communication channels, will proxies need to talk to each other?

Hi
Has anyone done a comparison of the compiled file size of swfs using Standard vs Multi-Core and both with LoadUp Utility?

Might be useful in cases where file size is an issue.

ok

http://forums.puremvc.org/index.php?topic=622.msg2781#msg2781

I have a queerystring utility class I'm instantiating from my main class.

If there are querystring key value pairs associated with the url that loads the application, I need to feed them into the application as they will determine what my application does on startup.

My question is, what is the best practice for doing this in  PureMVC app?

Should I pass any query string variables  into my ApplicationFacade startup method and then make them part of the first STARTUP notification?

Constants used by notifications that are mapped to commands, and might be used by more than one mediator, I store  in the Appplication Facade.

Other constants NOT mapped to any commands, I keep in the relevant view component. The latter would be used in both events dispatched by the component as well as the component's mediator.

Can anyone share their rationale for storing public constants and-or provide feedback on whether the above is recommended?
 

Another problem I have with the best practices example are the way the VO's are instantiated in the view components.
To me, this doesn't make sense and makes the views less portable.

Shouldn't knowledge of the VO's ONLY be held by proxys, commands and mediators?

I would suggest instead adding public getters to the view components for any properties the corresponding mediator wishes to grab and populating the VO's ONLY in  or via the proxys.

Most of the examples I've seen are Flex only and make ample use of Binding, especially when populating VO's.

Can someone give me an example of using VO's in an Actionscript only project?