I am not completely sure I have covered all the use cases here. I will try to list them out, let me know if I missed any.
1. All modules have defaultRoute set to dataModuleAddress. This is set from outside the module by the loader. Hence routeNotification without to
go to defaultRoute i.e.:- dataModule
// default route set to dataModule's application address
module.defaultRouteAddress = dataModule.applicationAddress;
2. To send system-wide messages to the shell or any other module use the to
argument with *
. This goes to everyone listening to this notification.
routeNotification("toEveryone", "foo", "bar", "*");
3. To send messages to modules loaded within View1/View2 use module groups. When loading modules within view1 set moduleGroup to "view1". And use this moduleGroup as to
when routing the notification.
// set the moduleGroup on the loaded module
module.moduleGroup = "view1"; // or something that indicates the view1 context.
// later route the notification within the view1 group context
routeNotification("toGroup", "foo", "bar", fabrication.moduleGroup);
4. This case is something you won't be using because of the dynamic nature of your application but makes sense to have in the framework. Suppose I need to send messages to all instance of Module1 that are loaded within View1. In this case, I can't use Module1/* because that would also go to all instances of Module1 that may be present in View2. So I am proposing another route, Module1/#. This translates to all instances of Module1 that are within the View1 group. The View1 group would be set on moduleGroup property.
module.moduleGroup = "view1";
// to send the notification to all instances of Module1 in view1
routeNotification("toModule1InView1", "foo", "bar", "Module1/#");
Does this cover all your use cases? Or am I missing something?
Regarding the use of the type
parameter to send information about the message. You don't need to do this. The notification object that you ultimately get in the destination module is of type RouterNotification. This is subclass of Notification and contains the message that carried the notification. You can do note.getMessage().getFrom()
to inspect the source of the message.
The use case regarding the view2 video player that should not respond to the notification until it is visible etc. This sounds like a good thing to implement with Interceptors. Interceptors are something I found in another open source framework called Parsley. Parsley is a Spring like IOC container with MVC support for Flex.
Parsley application events are like PureMVC notifications. Within Parsley, Interceptors allow you to trap application events based on some criteria. I am going to be implementing Interceptors in Fabrication soon but for Notifications. The idea is to alter/drop/multiply notifications enroute before they reach commands and mediators.
In your case you could create a simple interceptor that drops messages if the module is not currently visible, or hasn't loaded enough data etc. This keeps your normal application flow from being cluttered with special conditions.
 : http://www.spicefactory.org/parsley/docs/current/manual/mvc.php#config_interceptors