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

Show Posts

* | |

  Show Posts
Pages: 1 ... 4 5 [6]
76  Announcements and General Discussion / Fabrication / Re: Fabrication - Simplified PureMVC multicore modules on: October 15, 2008, 06:27:50
Hey Ruben,

I've just implemented fabrication in my application and it works great (saves me a lot of headaches right now Roll Eyes), so thanks for that!
Cool, Thanks.

I was wondering why the proxy classes don't have a FabricationProxy so they can routeNotifications too. Is this a design choice you've made or something that isn't implemented yet.
It wasn't a design decision, I just hadn't implemented it at the time of the initial release. I have added a FabricationProxy since, and it does have routeNotification. ;-)

I'm also curious what you think about the idea to store notifications that should be routed but can't be because there isn't a router connected to the module which sends the routeNotification. One module for example is routing some notifications to the log about what is happening in his initialization fase (in which he isn't yet connected...). As soon as the router will get connected, the stored notifications will be send along.
This would be a hard to do this at the initialization phase of the module because the internal pipe fittings need to be created before routing can work. I recently refactored the bootstrapping code. Instead of accepting a router, you set the router on the module loader. The module looks up this router as part of its initialization and connects to it. I was debugging some stuff where i forgot to set router on the module loader. So I basically added a rule that the router must always be set on the module loader.

peace,
darshan
77  Announcements and General Discussion / Fabrication / Re: Fabrication - Simplified PureMVC multicore modules on: October 14, 2008, 08:37:00
Repositories are one per project. This is the way the site works now, and automated tools that are being built make it important that it stay that way.
Ok, thats fine by me.

Also, we will need unit tests for your classes and asdoc. Compare to the Pipes utility if you're unfamiliar with unit testing or just looking for the level of documentation to provide.
I have improved the asdoc usage in the code considerably since the initial release. Regarding unit tests, I haven't written any unit tests yet, but I did run the PureMVC unit tests to verify that I didn't break any PureMVC internals. Fabrication was initially for an internal project in my company. I was under some time constraints at that time. I will start writing unit tests for it in a few days.

peace,
darshan
78  Announcements and General Discussion / Fabrication / Re: Fabrication - Simplified PureMVC multicore modules on: October 13, 2008, 07:52:13
Hey Cliff,

Partway through setting up the projects, I find the routing demo needs to be refactored into the PureMVC namespace first. It would be helpful if you could give it a name, say FabRouting, and refactor the classes into that namespace.

Thanks. I can do that, np. And yes the undo demo is also without a base package. I was trying to keep the package depth down in the demos. I will use the org.puremvc.as3.multicore.demos package for future demos.

About the repository, is it going to be a separate repository for the project and each demo? I was thinking of having one repository for everything with the below structure,

fabrication
   framework
      trunk
      branches
      tags
   examples
      fabrouting
         trunk ...
      simpleundo

Framework/trunk is the main line for the utility. Each example is under fabrication itself. I am not sure whether the trac integration would work with such a setup.

peace,
darshan
79  Announcements and General Discussion / Fabrication / Re: Fabrication - Simplified PureMVC multicore modules on: October 08, 2008, 10:43:46
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
80  Announcements and General Discussion / Fabrication / Re: Fabrication - Simplified PureMVC multicore modules on: September 22, 2008, 09:20:58
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
81  Announcements and General Discussion / Fabrication / Re: Fabrication - Simplified PureMVC multicore modules on: September 20, 2008, 10:20:23
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
82  Announcements and General Discussion / Fabrication / Re: Fabrication - Simplified PureMVC multicore modules on: September 18, 2008, 03:46:11
Joel, I have started the series on Fabrication undo's. Enjoy. ;-)

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

peace,
darshan
83  Announcements and General Discussion / Fabrication / Fabrication Undo (Part 1) - Simple undo demo on: September 18, 2008, 03:43:01
Hi All,

As I had promised earlier, I have posted the first of a series of articles about using undo with Fabrication at the blog. There are different types of undoable operations that Fabrication supports. This article explains how to work with property undos with a sample application. You can check it out below. Undo is a very important part of Fabrication, hope you like it. Thanks.

[1] : Post
[2] : Live Demo
[3] : Download Source Code

peace,
darshan
84  Announcements and General Discussion / Fabrication / Re: Fabrication - Simplified PureMVC multicore modules on: September 16, 2008, 10:11:23
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
85  Announcements and General Discussion / Fabrication / Fabrication - Simplified PureMVC multicore modules on: September 12, 2008, 02:51:59
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

Pages: 1 ... 4 5 [6]