Actually, then would you recommend architecting the system with as few commands as possible? My biggest issue with PMVC is that notifications can be handled in more than once place / methodology, and it seems to make app logic harder to follow. Not sure if you got my PM, but the sample app is here:

http://lukesh.com/files/AdeptivPMVC.zip

I'd really appreciate feedback.

I love that PMVC is so flexible, language agnostic, etc... but sometimes it feels like it gives you more rope than you need, and definitely enough to hang yourself with. I'm just trying to get a decent meta-meta-framework that will guide our development team for backend-y Flex apps.

Cliff, I see the point you are making, however my rationale was:

1. Modules do not necessarily need to be part of the display hierarchy, interact with the user, or create and export visual components (i.e. the view).

2. The list of loaded modules can be articulated in different ways in the view tier. For example, let's say that I had a module container that displayed the actual module, and another control that showed a button for each loaded module (both view components, both with their own Mediators). The ModuleProxy maintains an array of loaded modules and sends notifications indicating that the module is loaded and ready. Any Mediator observing can then articulate that as they need to, either by actually adding the module to the display hierarchy, or by simply creating a button.

Does this make sense?

...another thing that I felt was appropriate was using a ModuleProxy in the main application, versus storing modules in a Mediator, which it seems that every other demo does. In reality, loaded modules are part of the model, and their interaction with the user (that is, being added to the display hierarchy) alone is a view element. I'd love to get some feedback on this.

Also, I've included the app structure below which gives you the basic idea of what I'm trying to accomplish:

My context is a multi-module application, and instead of removing modules, I cache them and simply add or remove them from the display hierarchy. I never unload the PMVC cores.

IPipeAware modules have accept* methods but not corresponding remove* methods. When a module is unloaded, I would like to remove the plumbing. I understand that I could just leave the plumbing active and test whether or not it should receive messages, but I would have preferred to remove and re-add plumbing as needed.

I tried re-adding plumbing when a module was activated, which didn't error, but when I attempted to send a message the Pipe class RTE'd with a null output. It seems like there should be a clean way to remove any plumbing associated with a loaded module. I also feel like I may be overlooking something, or mis-implementing Pipes altogether.

I have what I feel to be a very clean and vanilla implementation of MultiCore and Pipes otherwise, and I'd love to release it to the community as a demo. Cliff, what is the best way to get this to you for your review? I think many could benefit from this.