Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: When to initialize commands, and question about Notifications  (Read 10498 times)
deltajam
Courseware Beta
Full Member
***
Posts: 25


View Profile Email
« on: December 06, 2007, 11:29:04 »

Ok,

I have an existing video application that has few distinct peices:

  • the Video Player
  • Channel List
  • Videos

The app loads all its data from a database, which is constantly changing.

Here is a breakdown of some of the events fired off in my application:

start app
load remotingProxy
establish rtmp connection
load channel list (loads channel thumbs, titles, etcs)
load first channel (creates horizontal list of video thumbs offstage, with titles, video frames)
show first channel (list moves on stage)
show first video
load videoplayer (sits ontop of video window, attaches videostream)
vp events (play, pause, stop, seek, mute, volume, fullscreen)
close videostream
next video
prev video
next channel
prev channel
..
.
etc.

This is just a few pieces of the main functionality. 

First Question:

Do all these get listed in the ApplicationFacade class as notification names?  What if my app was much bigger than this, would I list all 100+ notifications here?  If not, where would I list them? In my existing (very mediochre) architecture, the main pieces of fuctionality all have their own facade which lists notifications specific to that component.  I just need a straight answer, what is best practice for this scenario?

Second Question:

I'm trying to better understand the controller functionality in the PureMVC architecture.  Other than at startup, where and when would I need to register new commands?

Third Question:

In my application, would it be best to have one mediator for a set of components (such as the video boxes)? ... and if not, would I instaniate a new mediator for each videobox component after each one loads?  Same kinda goes for the channel list ...

If I manage to finish this application, I would be more than willing to provide a much simpler version (using xml sheets, and progressive video) as a demo.

I really do appreciate this new framework, and have spread the word to my fellow colleagues.  Thanks much Cliff!



Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: December 07, 2007, 12:39:48 »

There doesn't have to be a notification for each of these events.

Many of these events may be contained within the black-box wiring of a ViewComponent.

For instance, if your video player is a view component, many of these events (play, pause, stop, seek, mute, volume, fullscreen) would be handled within the component itself, and never need to be communicated to the PureMVC part of the system at all.

If your video player transport is one component and the playback screen is a separate component, each with its own Mediator, then it's possible you'd define constants for the notifications that these two Mediators need to agree upon for their communication. The VideoTransportMediator would listen to events (play, pause, stop, seek, mute, volume, fullscreen) from the VideoTransport, and in turn send notifications that the VideoPlaybackMediator would hear and in turn manipulate the state of the VideoPlayback component that's showing the video.

To your question about when would you need to register commands other than for startup, note that in the latter scenario, even though we sent a Notification it didn't trigger a Command. But it could have. For instance, if we needed to consult a Proxy or 2, do some calculation and and then trigger one or more Mediators into action placing the results into their viewComponents, a Command would be the place for that sort of thing.

Also, if you had a really large app and wanted to shorten the time it takes to send a notification around you could keep the observerMap short by registering and removing Commands that are only needed in a particular mode of the application, say.

-=Cliff>
Logged
Pages: [1]
Print