Hi All,

Regarding the issue with StateMachine and the respondTo syntax. This is easily solved using a new feature that I implemented a few days ago, Interceptors. Interceptors are like filters for PureMVC notifications. You can drop notification, alter them enroute, etc before they reach the PureMVC actors, Mediators and Commands. The idea is adapted from the Parsley application event interceptors feature[1]. Interceptors are very similar to commands and you can do everything PureMVC commands can do.

To implement Interceptors you need to extend the AbstractInterceptor class and implement the intercept method. The interceptor object is registered like commands with the registerInterceptor in commands or fabFacade.registerInterceptor method. Inside the intercept method you can,

• Alter the body/type of the notification
• Drop the notification
• Proceed with a different notification in its place
• Send N notifications before/after the notification

The StateMachine looks pretty useful. Good work Neil and Cliff. I have put up a demo of using the StateMachine with Fabrication[2]. The key class in the demo is the StateMachineInterceptor[3]. I have registered this interceptor with the StateMachine notification names. The intercept method checks for the presence of the StateMachine slash syntax, extracts the last part from the name and converts it to the form state<Changed|Action|Cancel>.

I checked the StateMachine source. It is listening to 2 of these notifications. So instead of altering the notification I am sending the modified notification for use with the respondTo syntax.

To clarify regarding the slash syntax, Fabrication uses the slash as a separator for routing notification across modules. The notification name is not altered at any point before, during or after transport. The slash in the to argument indicates the destination address of the target module of the notification not the notification name.

With Fabrication I have tried to keep things as compatible to PureMVC(Multicore) as possible. But If you have some specific feature/utility that does not work as expected, I will try to fix anything from Fabrication's pov as long as it makes sense. ;-)

Note, Interceptors are only present on SVN at the moment. I will be adding a release swc soon.

peace,
darshan

[1] : http://www.spicefactory.org/parsley/docs/current/manual/mvc.php#config_interceptors
[2] : http://code.google.com/p/fabrication/source/browse/#svn/examples/simple_fsm/src
[3] : http://code.google.com/p/fabrication/source/browse/examples/simple_fsm/src/interceptor/StateMachineInterceptor.as

I have committed the moduleGroup implementation to svn. The module group example i posted earlier should work now. Module group names must not have a / or # character in them. Also the A/# route and A/#groupName route is also working. Let me know if you find any bugs.

peace,
darshan

Hey Jason,

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;
routeNotification("toDataModule");

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[1]. 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.

peace,
darshan

[1] : http://www.spicefactory.org/parsley/docs/current/manual/mvc.php#config_interceptors

Hey Jason,

Can you post some of the routes you are using in your application? I want to make sure I have got everything covered.

peace,
darshan

Yes this is by design. Loopback messages are dropped. Use sendNotification within a module.

peace,
darshan

Hey Jason,

I looked at the grouping implementation today. I see no need to add another group argument to routeNotification. Current destination types are *, A/*, A/A0. So we can support group names directly with the condition that they should not have a / in their name. The current routeNotification's to argument would suffice. I need to modify the internals of routed notification to understand moduleGroups to avoid extra suffixes and such. The public api to work with groups would be something like,

:

// set the moduleGroup on module from outside
fabrication.moduleGroup = "myGroup";

// set the default route to point to this group
fabrication.defaultRoute = "myGroup";


You set the moduleGroup at the same place that you set the router on the fabrication depending on your platform and what you use to load the module. At the time of routing if to=null and a defaultRoute is set then the notification goes to the group name so any existing routeNotification would get sandboxed within that group.

This looks like a very useful addition. I will try to finish up the implementation by tomorrow.

peace,
darshan

Hey Greg,

This looks cool. Looking forward to the multicore version. ;-)

peace,
darshan

Hi Mark,

You are probably using older version of Fabrication. Please use the version on google code and its wiki. The blog articles are dated to the older version. I will try to add a disclamer to that post.

And as Jason mentioned the solution to your issue is to make getStartupCommand public.

Regarding the AIR application. The only difference between the flex and air version is that you have to extend AirApplication instead of FlexApplication. This is a Flex thing because the base class to extend for creating Air applications with Flex is WindowedApplication which is what AirApplication extends.

I will try to create a air demo example soon.

peace,
darshan

Hey Jason,

There isn't any easy way to do this within the framework currently. The firewall approach could work in a roundabout manner. Currently I am using the MultiRuleFirewall which is set to drop accidental system notifications. Instead you could use the PolicyFirewall with a custom policy function. The usage to install the firewall is,

:

var firewall:PolicyFirewall = new PolicyFirewall();
firewall.policyFunction = myPolicyFunction;

applicationRouter.install(firewall);
.

In the policy function you could alter the message to go to a fully qualified module address. Returning null drops the message. Something like, change to A/* to A/A0 if the message payload contained xyz or was within a certain container sprite etc.

This is all far from ideal though. I think your solution of using module groups is much better and in general would be a good feature to have within the framework. The changes are probably minor but spread across a lot of classes. I will explore the things required to implement this a little bit further and get back soon.

peace,
darshan

@Mark,

I checked this out in Flex Builder 3. You need to add the SimpleModule.mxml as a Module in the project via Project Properties > Flex Modules. However there doesn't seem to be a way to specify the output swf location/name in that dialog. So after adding it as module FlexBuilder.mxml will generate a file SimpleModule.swf in the bin folder.

You need to either rename this swf to simple_module.swf, or change the code in the shell to load SimpleModule.swf instead. The file to change this is, shell/view/MessageControlBarMediator.as#addModuleButtonListener.

peace,
darshan

@Mark,

Can you provide some information about any errors you are getting when building with Flex Builder?

peace,
darshan

@marsk416

There are some demos which are based on Flash CS3. In these examples you have to compile the flas. The rest use the mxmlc compiler. I am using Ant to compile these demos, but that is not necessary. You could use Flex Builder or any other IDE also.

With Flex Builder or any other IDE you will need to add the Fabrication swcs and its dependencies (PureMVC Multicore and PureMVC Pipes) to the libs folder or into the classpath. The source code for most of the examples is in src/main/flex or src/main/as3. In this case you need to set your main source folder in Flex Builder to the corresponding folder.

Can you tell me which demo you are having difficulty compiling?

peace,
darshan

Completely agree. One useful side effect I have noticed is that Mediators can be tested much easier if you use the onRegister method instead of the constructor.

peace,
darshan

Hi Mark,

I am working on improving the documentation. I have added several pages to the wiki to get things rolling on this front. You can check out the below links.

peace,
darshan

[1] : Features
[2] : Getting Started
[3] : Using modules with Fabrication
[4] : Using reflexive notification interests
[5] : Using reflexive mediator registration
[6] : Building Fabrication

Mark,

Fabrication is built on top of PureMVC multicore. Hope that helps.

peace,
darshan