Wow that's quick Darshan! Thanks. You've really done a great job with 0.4  .

I've been busy refactoring some of my own code and finally everything is working again with 0.41 so that's quite a relief.

One question I have so far is about the new FabricationProxy.
I have several modules who's proxy extend the same base proxy, named "DataProxy". When they extend "DataProxy", they don't change the ProxyName because I wanted them to share a couple of Commands which fill the "DataProxy".

So in my situation you have "Module1Proxy" and "Module2Proxy", which both extend "DataProxy" and therefore are both registered as "DataProxy" (within their own core). When one of them get's filled they send a notification "DATA_SET", but because the registered name ("DataProxy") is not the same as the classname ("Module1Proxy"), the fabricationproxy class changes the notificationname to "DataProxy/DATA_SET". So the notification never reaches my mediator...

So my question is, why does the notificationname get changed when the registered proxyname is not same as the classname?


Here are some other small comments, but nothing really big so far.
A small addition to the FlexModule class is to add some event metadata

:

[Event(type="org.puremvc.as3.multicore.utilities.fabrication.events.FabricatorEvent", name="fabricationCreated")]
[Event(type="org.puremvc.as3.multicore.utilities.fabrication.events.FabricatorEvent", name="fabricationRemoved")]
Although I've seen a "removeEventListener" for every "addEventlistener", another addition I've made myself is to add "false, 0, true" to every addEventListener call to make sure those references won't cause any memoryproblems... (yes I know, not really necessary)

Tnx,
Ruben

Darshan,

Thanks for your quick response. Here is some code of when I used the old fabrication, so I hope this clarify's it a bit.

Quick description:
My application call's the loadPlugin method for every "plugin" it want's to use. When the application is started, there can be many instances of every "plugin" so when the user wants a new instance, it calls PluginManager.getModule(...) which then returns a new instance of the requested plugin.

The PluginManagerMediator listens to the events of the PluginManager and connects every instance of the plugin that's created.

PluginManager:

:

public function loadPlugin(pluginVO:PluginVO) : void
{
var module:IModuleInfo = ModuleManager.getModule(pluginVO.filename);
module.data = pluginVO;
module.addEventListener(ModuleEvent.READY, onModuleLoaded, false, 0, true);
module.addEventListener(ModuleEvent.ERROR, onModuleFailedLoading, false, 0, true);

//add module to the loading queue
modules.push(module);

//dispatch an event that the module is getting loaded
dispatchEvent( new PipeEvent(PipeEvent.PLUGIN_IN_QUEU, pluginVO) );

module.load(ApplicationDomain.currentDomain);
}


protected function onModuleLoaded(e:ModuleEvent) : void
{
var module:IModuleInfo = e.module;
var pluginVO:PluginVO = module.data as PluginVO;

//remove module from loading queue
removeModuleFromQueue( module );

//add module to available modulesList
components[ pluginVO.title ] = module;
pluginVO.loaded = true;
}


/**
* ComponentFactory.
*
* @param name name of the component which should be instantiated
* @return instance of the requested component
*/
public static function getModule (data:ModuleVO):FlexModule
{
var module:IModuleInfo = components[ data.type ] as IModuleInfo;
var component:FlexModule = module.factory.create() as FlexModule;

instance.dispatchEvent( new PluginEvent( component, PluginEvent.CREATED ) );
component.addEventListener(FlexEvent.INITIALIZE, instance.onPluginReady, false, 0, true);

return component;
}
PluginManagerMediator:

:

protected function onPluginCreated (event:PluginEvent) : void
{
event.plugin.setDefaultRoute( applicationModuleAddress.getInputName() );
}


protected function onPluginInitialized (event:PluginEvent) : void
{
event.plugin.acceptRouter( applicationRouter );
}

Hi Darshan,

I've just started to implement this new version. First thing I've noticed is the direct relation with the FlexModuleLoader in FlexModuleFabricator. Because of this relation it is now impossible to load modules without the ModuleLoader (I always used the ModuleManager). In the previous version I could just manually call setDefaultRouter and acceptRouter... Is there any way I could still use the ModuleManager to load my modules (I don't like the overhead of the ModuleLoader...)?

Thanks it advance, and I will give more feedback as soon as I got better knowledge of all the changes  .

Ruben

Hi Darshan,

I've just implemented fabrication in my application and it works great (saves me a lot of headaches right now ), so thanks for that!
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. If it's a design choice, what solution is there for sending notifications from the proxy to other modules? (with a special command/mediator to handle proxyRoutes, I'm just bringing back the JunctionMediators)

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.

Thanks in advance,
Ruben