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

Hello Forum:

I'm a certified .NET developer, but I'm new to the Flex/Flash world.  We are moving three of our applications into the cloud, and after two months of research, have decided on Flex (Flash Builder 4.0), MultiCore PureMVC (without Pipes for now), and ColdBox (on top of ColdFusion 9.0 ORM) as our technology stack of choice.  The architecture for each will following 'modularity' pattern.

Consider the following as you read on: Modules will be dynamically loaded.  The shell will have no foreknowledge of the modules that will be loaded into it, other than of the Administration Module.

I have a few questions concerning directory structure.  Following Joshua Ostrom's example, I'm thinking that I should have separate projects for the shell, for common, and for each module.  In the .NET world, we have the same problem with our AppDomains that you guys have with ApplicationDomains: Once a module ('assembly' in .NET) has been loaded into an AppDomain, it cannot be unloaded.  It's my understanding that the foregoing approach to separation facilitates mitigating, or eliminating altogether, GC issues and ApplicationDomain issues.

From what I've read around the forum, and in the Adobe documentation, it would be advisable to treat the framework SWC as an RSL, PureMVC MultiCore as external, and then place the two of them (along with another other common elements) into a separate Flex Library Project--perhaps called 'common'.

I've tried this, though, and even referencing 'common' from the main application project, the application can't find what are obviously framework classes (e.g. 'Object').  What am I doing wrong?  I can't quite seem to find the answer (even after reading chapter 30 of the Developer's Guide for Flex 3.0).

Also, there are a number of so-called 'framework' SWCs: the canonical, along with a number of ancillaries (playerglobal.swc, textlayout.swc, etc.).  What should the linkage type be of each?

Also, in the .NET WinForms application that I wrote (which we currently use), I took the approach of creating a ModuleStub for each Module.  While the Modules are loaded lazily, the very thin ModuleStubs are enumerated (from a file directory) and loaded all at once.  The stubs contain just enough information to set up the lattice: a small icon, a larger icon, the module name, the order of the module in the navigation pane, the facade, etc.  Communication between module and shell is done through interfaces (I did all of this before the advent of the .NET System.AddIn namespace in .NET 3.5).  From what I've read in another post on this forum, I will want to set up a similar scheme with PureMVC.  Is that correct?

Your help would be much appreciated.

By the way, PureMVC MultiCore is wonderful.  I spent about six months developing my own modularity scheme in .NET.  I'm quite relieved not to have to do it again, other than I'll have to develop a bootstrapping scheme for loading the modules.

Thank you.

Eric