Architecting PureMVC Flash Video Player

[poser187]

Hey Guys,
I've used PureMVC on a few applications that I've built recently and have a pretty decent understanding of the Framework (although admittedly, I'm still learning a LOT!). I'm about to start a new project building a video player in Flash. The player will have a number of components including a controlbar, playlist, menus, etc. as well as the main video object to display the video stream.

What I'm trying to figure out is best practices for architecting this type of application.
1) Would the NetConnection / NetStream and Video Object be stored as part of the model? If so, then how would this be attached to a view component?

2) For other view components such as the playlist, and menus, if they are not going to ALWAYS be shown, would I need to create a model to determine whether or not these items are shown, then have a command that determines which items to attach to the view based on the model?

Other thoughts or suggestions would be greatly appreciated. Basically I'm just trying to wrap my head around the architecture as much as I can before I dive in.

Thanks to everyone taking part in the forums, and the community in general, it has been a HUGE help to me in learning to use this amazing framework!

-Kyle

[puremvc]

The NetStream and NetConnection can be created and maintained by a Proxy who sends them on a VO (along with any other info the player needs) in the body of a notification, which the player's mediator is interested in and responds by setting the VO on the custom player component. The player component should have a top level property for this VO, and bind to its properties to get the stream and whateve else it needs.

Also, for the "sometimes controls aren't displayed" part consider using the StateMachine utility. You define an FSM (finite state machine) wherein all the discrete states of your application (not just the view) and how the app moves from state to state are defined in xml. An FSM injector can be used to parse this xml and inject a fully configured StateMachine into your app, ready for use.

You define an initial state in your FSM. In any given state, there are some number of possible target states, each associated with an action.So as the app runs, you trigger state transitions by sending StateMachine.ACTION notifications to move from state to state. During a state transition, the StateMachine can send a notification indicatiing the current state is being exited, and then one that says the target state is being entered. On exiting or entering a given state your controls mediator may be interested and show or hide its controls. Presumably this would not be the only two states of the app (controls hidden or shown). if so, the StateMachine is probably overkill since the notes that would change the state could simply be heard by the mediator and used to turn on and off the controls.

But putting elements of state such as whether the controls are on or off is generally not the best approach.

-=Cliff>