Fabrication - Simplified PureMVC multicore modules

[Darshan Sawardekar]

Hi All,

I want to present a new PureMVC utility called Fabrication. The objective of Fabrication is to simplify the process of developing modular PureMVC multicore applications.

Fabrication is a collection of common ideas that I was using in applications built on top of PureMVC multicore. A Fabrication application is just like any other PureMVC application, with a few optimizations and shortcuts. It is based on the Pipes utility of PureMVC multicore, and some other related ideas I found in the open source video conferencing project, Blindside.

I found that the Puremvc Facade's behaviour is common across most applications. A facade.startup(app:Object) call initializes the PureMVC apparatus, A startup command is registered with it to do bootstrap work. This process was common to almost all my applications. So I decided to create a standard Facade implementation with a StartupCommand registration and a STARTUP notification.

By eliminating the need for a concrete facade, the work of bootstrapping Proxies, Mediators, etc was shifted to the StartupCommand. Since this is common for all applications I implemented a FabricationApplication extending mx:Application. In the process I was also able to setup automatic multiton key generation. With Fabrication, the only thing needed to hook into the PureMVC apparatus is to override the FabricationApplication's getStartupCommand method. Sample code is below,

:

<?xml version="1.0" encoding="utf-8"?>
<fab:FabricationApplication
xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:fab="org.puremvc.as3.multicore.utilities.Fabrication.components.*">

<mx:Script>
<![CDATA[
import myapp.controller.MyAppStartupCommand;

override protected function getStartupCommand():Class {
return MyAppStartupCommand;
}

]]>
</mx:Script>

</fab:FabricationApplication>
An important part of Fabrication is its support for modules. Fabrication comes with a custom FabricationModule class that extends mx:Module. It also bootstraps in the same way as a FabricationApplication, with the getStartupCommand() method.

FabricationModules come fitted with standard pipe fittings. However instead of creating manual fittings to establish communication between modules, a principle of routing is used. The routing metaphor eliminates the need to create JunctionMediators and the translation of pipe messages into internal module notifications and vice-versa. The corresponding mxml code for the module is,

:

<?xml version="1.0" encoding="utf-8"?>
<fab:FabricationModule
xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:fab="org.puremvc.as3.multicore.utilities.Fabrication.components.*">

<mx:Script>
<![CDATA[
import mymodule.controller.MyModuleStartupCommand;

override protected function getStartupCommand():Class {
return MyModuleStartupCommand;
}

]]>
</mx:Script>
</fab:FabricationModule>

The module is loaded into the application using the FabricationModuleLoader which extends mx:ModuleLoader. Since typical configuration in modular applications is shell-module, the default communication route for the module is set to the shell. The module loading code is,

:

var moduleLoader:FabricationModuleLoader = new FabricationModuleLoader();

moduleLoader.url = moduleDescriptor.url;
moduleLoader.router = applicationRouter;
moduleLoader.setDefaultRoute(applicationModuleAddress.getInputName());

moduleLoader.addEventListener(FabricationModuleEvent.MODULE_INITIALIZED, moduleInitializedListener);
moduleLoader.loadModule();

The most interesting part of all this is the communication between module and shell. Instead of sending and receiving messages via the junction.sendMessage and handlePipeMessages, messages are routed as standard PureMVC notifications. To send messages to other modules you call routeNotification. And to receive messages from different modules you simply add the notification name in listNotificationInterests of your Mediator. Or instead you can register that notification name with a command. The routing code is below,

:

// to listen to a routed notification from the shell, in the module's mediators use,
override public function listNotificationInterests():Array {
return ["MESSAGE_FROM_SHELL"];
}

// and handle the notification as you would in PureMVC
override public function handleNotification(note:INotification):void {
if (note.getName() == "MESSAGE_FROM_SHELL") {

}
}

// to send a notification to the shell use,
override public function onClick():Array {
routeNotification("MESSAGE_FROM_MODULE", {foo:"bar"});
}

The routeNotification method has an additional 4th parameter, "to". Use "to" for specifying the module to which you wish to send the message. This method is provided by extending FabricatonMediator or via facade.routeNotification.

:

// to send a message to all modules, use *
routeNotification(noteName, noteBody, noteType, "*");

// to send a message to all instances of a specific module use, ModuleName/*
routeNotification(noteName, noteBody, noteType, "ModuleName/*");

// to send a message to a specific module use
routeNotification(noteName, noteBody, noteType, "ModuleName/ModuleInstanceID");

In summary to build modular Fabrication applications you need to do the following,

• In the shell, extend FabricationApplication and implement getStartupCommand.
• In the module, extend FabricationModule and implement getStartupCommand.
• Mediators extend FabricationMediator.
• To send notifications between modules use routeNotification.
• To listen to routed notifications use, listNotificationInterests or map a command to that notification.

Fabrication also contains some other useful features like multi-level undo, routing firewall for controlling communication between modules etc. I will talk about some of these things in future posts.

I want to thank Cliff Hall for creating PureMVC. It has made my Flex programming much more fun. Also thanks to the folks behind the Blindside project. The routing principles mentioned above are adapted from Blindside.

Download the Fabrication utility here.
Download the Fabrication routing demo application with the binaries here.
The live demo is here.

I would love to get feedback from the community about Fabrication. Thanks.

peace,
darshan

[puremvc]

Darshan,

This is pretty cool stuff. I like the firewall/router concept. I won't have time to dig into this deeply just yet, but I'm sure others here will. I did peruse the code enough to see that it's definitely sound in concept.

I notice you've packaged it properly for the PureMVC utility space, would you like me to set up a repository and trac site? There is a backlog of this work, but I will get to it if you'd like to offer it up.

-=Cliff>

[Joel Hooks]

Wow. This is a really cool utility. I love the router/firewall metaphor. The undoable command structure is interesting also, and I would love to see simple examples of this stuff in action.

I want to thank Cliff Hall for creating PureMVC. It has made my Flex programming much more fun.

QFE

[Darshan Sawardekar]

Thanks all for your comments.

Joel,

I am working on sample applications to explain the undo/redo functionality of fabrication. It is like a series on different types of undo's that applications generally require. I will be releasing this in the next few days.

Cliff,

It was my intention to contribute Fabrication as part of the PureMVC utilities. If would be great if you can setup the repository and trac for this. With regards to the sample applications mentioned above, I have modified the EmployeeAdmin sample application from PureMVC standard demos to use Fabrication's undo/redo. Is it ok to release this? Should I send you the files first?

peace,
darshan

[tinils]

Wow!..great work! Thank you for this.

[Darshan Sawardekar]

Joel, I have started the series on Fabrication undo's. Enjoy. ;-)

[1] : Fabrication Undo (Part 1) - Simple undo demo

peace,
darshan

[Joel Hooks]

Awesome, thanks Darshan.

I have a question. I have several Air applications that I'd like to Fabricate. Should I just make a new class called FabricationWindowedApplication that mirrors the code in FabricationApplication but extends WindowedApplication instead? Do you think there is a better way to do this? I hate to repeat all the code, but I can't see another way.

[Darshan Sawardekar]

Joel,

Thats the good point, I hadn't thought of the different type hierarchy issues with Air. There is similar duplication in the FabricationModule and FabricationApplication classes, had ignored at that time. Extending a class with the Fabrication hooks is required and cant be avoided. I will look into refactoring some of the internals to prevent this duplication. I am thinking something on the lines of,

FabricationBootstrap
   < FlexApplicationBootstrap
   < AirApplicationBootstrap
   < FlexModuleBootstrap
   and possibly < FlashApplicationBootstrap also

Move the duplicate code into the Bootstrapping classes and implement different concrete bootstrappers as needed. The IRouterAwareModule interface will still need to be implemented by the main application classes like FabricationApplication, FabricationModule, etc, but this would be limited to calling methods on the bootstrapper instances. And it keeps open the possibility of using Fabrication with flash cs3 applications, something I have been meaning to address also.

:

public function acceptRouter(router:IRouter):void {
   bootstrapper.acceptRouter(router);
}

public function getModuleAddress():IModuleAddress {
   bootstrapper.getModuleAddress();
}

Sound reasonable? Your thoughts.

peace,
darshan

[diamondTearz]

WOW!    uh...Wowww!!  Okay so I spent my whole morning cursing and blessing Pipes and the associated utility(mainly because my brain was full and dizzy trying to get it) and I accidentally happened upon this!).
Thank you so much!!  I will get little to no sleep tonight messing with this but that's okay!!!   I can already tell it will save me countless hours in the future!

[Darshan Sawardekar]

Thanks diamondTearz, I am glad you like it. Fabrication just sets a convention using standard pipe fittings that works well for multi-module applications. It saves a lot of time due to the elimination of code to do message-to-notification and vice-versa.

peace,
darshan

[Vernon Haughton]

Darshan,

Are there plans to create a version of Fabrication for AS3 only projects?

[Jason MacDonald]

Any PMVC Utilities that require the MX package makes us Flash CS3 guys sad programmers

I'm going to have a look through the code and see what I can do to adapt it to work with Flash... though I may have to rewrite a lot to be more like your example above (extending bootstrap) to get it to work.

EDIT: Now that I've looked through the code, there's just far too much code to go through and change while trying to learn how the utility works. Nice work anyways. I'll anxiously await a CS3 version.

[Darshan Sawardekar]

Hi Jasonmac, Vernon,

Fabrication isn't meant to be a Flex specific PureMVC utility. I realized a few errors in the design after the initial release. I have fixed a good part of these issues since. Like Joel suggested above, there wasn't very clean way to create custom fabrications for say flash, air, etc.

The basic premise of the refactoring is instead of FabricationApplication, FabricationModule, etc there are application context specific fabrications ie:- FlexApplication, FlexModule, AirApplication, etc. The internals have now been refactored to use an adaptor so there isn't much code duplication in the concrete fabrication classes. There is a clean breakup on the mediator side also with separate FlexMediator and a FlashMediator. And creating new fabrications is much easier with the ApplicationFabrication abstract class.

The refactoring is pretty much done, I am waiting on Cliff to setup the project SVN. Fabrication is getting much more stable now. Moving forward I want to avoid releasing arbitrary zip files on the blog. Just a little more time... ;-)

peace,
darshan

[Jason MacDonald]

Great news! Thanks for your hard work, it's appreciated. I can't wait to give it a go. Though it might have to wait till my next project since the one I'm doing now is under a tight deadline.

[puremvc]

Thanks for hanging in there and continuin to improve the code, Darshan. I have about 12 projects queued to be set up right now. Since even one takes minimum half a day because of the sundry admin associated with it, I'm trying to do them all in parallel. I'm part way done with your setup, but not all the way. I'm busting it hard on the job this week to try and clear an extra day or half day Friday to get it going.

Fear not, the repo awaits in the near future.

-=Cliff>