|
Title: True Modularity Post by: ebaggg on July 17, 2008, 11:01:28 I am a little confused with the modularity concept. I have an app that has a main swf (major view components) and the module swfs, which contain the specific view components for the pieces of the app loaded at runtime (based on settings).
The problem I see, which the Modularity demo has as well, is that all the module (CoolWidget) code is compiled into the main swf and the module swf. The ApplicationFacade references the StartupCommand, which references the CoolWidgetMediator and CoolWidget mxml views. My module swfs have a lot of view code, so in a true modular app, it seems wasteful to have all that code compiled in the main swf too...however, I cannot instantiate the Module mediator class without having that class compiled in the main app swf, and if I do that, all the view code comes with it. Thoughts??? Thanks, Kevin Title: Re: True Modularity Post by: puremvc on July 17, 2008, 01:32:08 The Modularity demo has a lot of ground to cover, and the primary focus of it is the communications by interface between the shell and the modules.
In a real project you can separate out your modules into separate projects, create a shared 'API' project that has just what needs to be shared between the modules and the shell. Then the client builds in the API library and loads the modules. The modules should be compiled with the API being 'external', not 'merged into code'. The main app merges the API into its code and provides it to loaded modules, so they don't have to be compiled with it. -=Cliff> |