is it bad practice to use a Mediator purely for processing Notifications (and sending out new Notifications accordingly), where the Mediator has no view component?

the specific scenario that's given rise to this question:

DownloadProxy sends Notifications; complete, progress, error, cancelled, etc.  the app needs to react to these Notifications in various ways.

i could create separate Command classes to process each of these different Notifications, but that seems excessive.  instead, i'm thinking of creating a Mediator that is interested in all of those Notifications, processes them, and sends out reactive Notifications.  it keeps everything grouped in one spot and all of that behaviour is related so i don't see a need to modularize it all out into separate Commands.

anything wrong with this approach? 

i'm switching from flex 3 to flex 4 and i'm hitting a few snags.

i create all my mediators in ApplicationMediator.  in flex 3, i listened for the ADDED_TO_STAGE event in ApplicationMediator to get references to all the instantiated views in the app.  now in flex 4, i get null references on a lot of the views within that added_to_stage event.

i'm probably missing something very basic here, but haven't been able to figure it out.  what event should i be listening to with ApplicationMediator to ensure that all of my views in the app are instantiated?

i've got a multiuser interface that communicates via FMS. would it be possible to serialize notifications and broadcast them to other application instances, via Flash Media Server? i want to avoid a lot of building classes to translate what comes in from FMS, and just pass the message along.

thanks for the help so far

i'm using the Undo utility with PureMVC and it seems like i can use the Command stack in the CommandHistoryProxy to implement persistent application state.

i'm building a media viewing/editing application, it will be heavy on UI components.  lots of windows and buttons and options.  i would like to take a snapshot of the overall application state, store it, and use it to replicate that state at a later time.  (stored to a database most likely).

what i'm thinking so far is that to take that snapshot, i can simply look at the Command stack, and serialize each individual command out to a database, and later read them in, in order, reconstruct them and execute them to rebuild the application state.

am i taking the right approach? it seems i would have to write a serialize/deserialize function for each Command, or perhaps use a CommandFactory that builds these Command instances.

i'm just wondering if i'm on the right track here, or if there's some other part of PureMVC that i should be looking at.

thanks for your time
adam

i'm new to pureMVC, so tell me if i'm going in the completely wrong direction.

i'm wondering if i need a ViewComponent registry, similar to the registries for mediators and proxies.

i have a custom view component, MediaPlaybackUI. i create them dynamically at runtime, there can be multiple instance.  i do the construction of MediaPlaybackUI in a Command, then send a Notification of this new instance.

elsewhere, a Mediator is listening for this notification.  the Mediator has a reference to a class i've called MediaDisplayUIsLayoutManager, which deals with the visual layout of all the MediaPlaybackUI instances. 

should i store the MediaPlaybackUI instance in a view component registry, and then retrieve it when the notification of the new instance gets to the Mediator?  or should i pass a reference the new MediaPlaybackUI instance inside the body of the Notification?

if a ViewComponent registry is the right way to go, should i add registerView/removeView/retrieveView  to ApplicationFacade, and cast facade to ApplicationFacade each time i need to access the view component registry?

thanks for the help