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.
