Sorry, about that, I am planning on posting the full source after refactoring to clean it up.

Josh

The approach I took was to have the module 'cache' the fittings when connecting them.

:

module.cacheFitting(moduleToApp,appIn);

:

public function cacheFitting(localFitting:IPipeFitting,remoteFitting:IPipeFitting):void
{
cachedFittings.push({local:localFitting,remote:remoteFitting});
}
Then, when it comes time to unload a loaded module, I simply 'cleanup'

:

public function cleanup():void
{
while(cachedFittings.length > 0)
{
var localFitting:IPipeFitting = cachedFittings[cachedFittings.length-1].local;
var remoteFitting:IPipeFitting = cachedFittings[cachedFittings.length-1].remote;

if(remoteFitting is DynamicTeeSplit)
   (remoteFitting as DynamicTeeSplit).disconnectFitting(localFitting);

localFitting.disconnect();
cachedFittings.pop();
       }
}

Hope that helps!!!

Thanks, glad the diagrams helped (a picture is worth 1024 words ). 

I went ahead and posted the 'pipes' version of the mortgage app.

http://www.joshuaostrom.com/2008/06/17/pipe-demo-mortgage-app/

I apologize for all the linking!!

Agreed. 

The first diagram (that Mike posted above) was pertaining to an implementation that allows an application to load modules that, in turn, load modules (a parent, child, grandchild implementation).  Probably can [should] be safely ignored for anyone just getting their feet wet [pun??] in pipes.

Thanks again for this great utility Cliff!!

BTW, I'm happy to report it's [the Pipes utility] working *great* in the enterprise app(s) I'm working on.

You can get info on that diagram, in context, at http://www.joshuaostrom.com/2008/06/13/pipe-architecture/

Regarding an overview of using pipe's I posted at
http://www.joshuaostrom.com/2008/06/15/understanding-puremvc-pipes/.

This diagram would probably be better for those trying to conceptualize the architecture.  The diagram illustrates an app that loads two 'child' modules.




Hope that helps!!!

No problem.  I've posted an architectural diagram over at http://joshuaostrom.com to help anyone working with the Pipes Utility.

Josh

I refactored the MortgageApp to use the pipes utility.  I like the approach the Pipes utility takes - build the module-app app-module integration on top of the exisiting modules (i.e. add a junction  mediator to your exisiting module and ensure your module implements IPipeAware).

Cool stuff Cliff.

I did run into a question however.  I'm finding the need to disconnect individual 'pipes' from a TeeSplit or TeeMerge - not simply 'all' pipes. 

For example, my 'shell app' has an outbound (TeeSplit) and inbound (TeeMerge) pipe.  Dynamically loaded modules create pipes and connect to the latter 'shell' pipes.

When it comes time to unload a dynamically loaded module, I currently don't have a way to remove to the connection to the app's TeeSplit / TeeMerge without disconnecting all of the other modules' pipes as well. 

I simply subclassed TeeSplit and added function to disconnect the passed fitting. 

:

public function disconnectFitting(output:IPipeFitting):IPipeFitting
Doing so solved my problem.

*If* I'm not missing something, it might be worthwhile to add the latter function to TeeSplit.

Thanks

Thanks,
  I've posted a [quick] AS3 demo as well http://dluminosity.com/blog/2008/05/24/as3-puremvc-dynamic-modules/ for those interested.

Kevin,
  I've posted a quick demo at http://dluminosity.com/blog/2008/05/24/as3-puremvc-dynamic-modules/.

  I didn't take the time to build a menu system.

 It's one possible approach, keep an eye on the Pipes utility Cliff is working on

Exciting stuff Cliff, THANKS!!  It's always great to see a knowledgeable architect at work

Yes, I settled on inbound / outbound notification mappings being defined statically.  This turned out to be a better approach.

thanks again!!

Okay,
 I've posted a working demo at http://dluminosity.com/blog/2008/05/19/dynamic-flex-modules-with-puremvc/. 

The application->module, module->application 'bridge' resides in a function added to the module's facade...

:

   
 override public function initializeMappings():void
{
    outboundMappings:Array = new Array();
    outboundMappings[QUOTE_GENERATED] = EventNames.LOAN_QUOTE_READY;

    inboundMappings = new Array();
    inboundMappings[EventNames.REQUEST_FOR_LOAN] = QUOTE_REQUESTED;
}

The module will 'subscribe' to any notifications in 'inboundMappings.'

Cliff,
  I should have let the dust settle before posting.  Please disregard the request

(This was to support the change in a dynamically loaded modules "notification Interests" over time - I've settled for a much cleaner approach).

I've been cleaning up my code (hoping to post it soon) on dynamically loaded modules. 

First off, I realize the View can be sub-classed easily - this is just a suggestion to avoid the need of doing so.

I came across the following function in the View class

:


public function removeObserver( notificationName:String, notifyContext:Object ):void
{
// the observer list for the notification under inspection
var observers:Array = observerMap[ notificationName ] as Array;

// find the observer for the notifyContext
for ( var i:int=0; i<observers.length; i++ )
{
if ( Observer(observers[i]).compareNotifyContext( notifyContext ) == true ) {
// there can only be one Observer for a given notifyContext
// in any given Observer list, so remove it and break
observers.splice(i,1);
break;
}
}

// Also, when a Notification's Observer list length falls to
// zero, delete the notification key from the observer map
if ( observers.length == 0 ) {
delete observerMap[ notificationName ];
}
}


This works great when the mediator has a static lists of interests.  However when that list is dynamic some problems can arise. 

My request is for the addition of a simple check that

:

var observers:Array = observerMap[ notificationName ] as Array;

didn't return null...

:


if(!observers)
   return;


What do you think?

Thanks for the reply!!

I glad to say I've got it working
With a few changes to my original 'brain storm.'  Here's what I ended up with...

My modules communicate w/each other and the parent app.  Likewise the parent app communicates w/each module.  The parent app has NO IDEA what modules will be loaded or how many.  The modules are loaded / unloaded dynamically at runtime.  This provides me with the scalability I was shooting for - my parent app doesn't have to be re-compiled for every 'nth module I write.

I'm staying fairly well encapsulated as well - my modules don't reference the parent app, it's facade or anything like that.