- the charts are in modules, optimized for the single host This sounds the most reasonable.
If the modules need to be loaded into another shell they can be re-compiled for that purpose. I have each module in its own project and run the deploy build via ant. --- In flexcoders@yahoogroups.com, "Richard Rodseth" <[EMAIL PROTECTED]> wrote: > > I'd appreciate some input on my module strategy. > > I'm working on a charting application with a requirement that > individual charts be embeddable as "widgets" on arbitrary pages. > > I already have the bulk of the code in libraries, so have some freedom > to explore different packaging. > > I had originally thought that it would make sense to create a module > for each chart, and two separate "hosts", one main application and > one widget host. I understand that I would have to use RSLs and > framework caching to keep the module size down. Frankly, I'm a little > wary of that given the time constraints, and also because it depends > on the later player. > > Another approach was to just build a different application SWF for > each widget and modularize only when the main app becomes too large. > > Now I am considering the following: > > - the host is a single SWF with two states (widget and full). It loads > either one, or several modules based on runtime config > - the charts are in modules, optimized for the single host > - the single app and multiple modules are in one project, so I can > optimize for that app in Flexbuilder (though we do have continuous > integration set up too) > > The only downside I can think of is that if the "full" state of the > app has a lot of code besides the module code, the size of the widget > download will be larger than it needs to be. On the other hand, it > would allow the full app to be embedded as a widget, since the UX > would be determined at runtime. And I suppose the "full" host state > could itself be modularized. > > Comments? Thanks in advance. >
