Follow-on to topic concerning "fully encapsulated modules"

[estaylorco]

Directed to Cliff,

Hello, Cliff.

I was just reading a reply you made to a post concerning "fully encapsulated modules."  In it, you state the following:

You need another actor that is responsible for managing the modules. Much as the Model keeps a map of Proxies, this actor keeps a map of modules. This actor also needs to be able to take configuration from the other actor and use it to create factories for modules, create (or defer) loading of each module, as well as creating or deferring some configured number of instances of each module once loaded. It should keep the factory on hand to lazy load configured modules.

Who would that actor be?  In the .NET library I wrote, the 'ModuleLoader' resided in the shell.  That seemed to be the best place for it.  Would you agree?  Perhaps the loader should be its own module, except that, unlike other modules, it's not obtained from a file directory.  It's loaded in the same way that modules are loaded in your [wonderful] Modularity demo.

Thank you.

Eric

[puremvc]

In PureMVC, this actor can best be implemented a subclass of Mediator. It ends up being a bit of a heavy class no matter how you implement, but a Mediator makes sense because:

1) it is a long-lived actor
2) you can send it notifications

The perspective I have is that mediators often create their own view components which is what they usually mediate communications with. So it is reasonable for them to create the loader components based on incoming configuration notifications and tell those loaders to load their modules. It is reasonable that they may also respond to notifications to export references to their modules for inclusion in the view hierarchy.

-=Cliff>

[estaylorco]

Yes, I think this makes sense.  The Mediator is analagous to my ModuleStub.

Thank you for your guidance.

Eric