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

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?

Okay we’ll as close to ‘fully’ as one can hope for :-)

I’m fine with the modules dispatching events and the shell app picking those events up.  Likewise I have no problem implementing the modules to a common interface to facilitate shell->module communications.

I’m hoping to achieve the following…

1) Modules [swfs] dynamically loaded /unloaded during runtime. 
2) My ‘shell’ app won’t know what modules will be loaded at compile time. (Read in from config / rpc / IoC scheme / etc @ runtime).
3) Each modules ‘mediator’ code will reside w/in the module NOT the main app.

Any tips on doing this (i.e. #3)?

I'm hoping there are some flexbuilder gurus out there

 I'm using the standalone version of FB3 and was wondering if there's a way to 'automate' my PureMVC project creation.  That is, create the model, view, & controller folders, my ApplictionFacade.as (and contents thereof) the StatupCommand, ModelPrepCommand, etc.  Basically the PureMVC 'shell' I have to manually recreate each time I start a new PureMVC project.

Is there some type of template or plug-in I can utilize to do this??

In many of the demos I've seen the mediators are directly referencing components [TextInputs for example] within the view. 

Would it be better decoupling to have the view pass the corresponding VO *with* the Event as opposed to having the mediator catch the event, and then "dig into" the view component to "pull out" the desired data (i.e. construct a VO from components w/in the view component)?

Just wondering.

The mediators seem to be so tightly coupled to the view components.  Are more verbose events worth the effort or am I being too anal?