Have you considered writing some of your libraries as ActionScript (only) libraries? Just a thought though. at the point you realize that things are getting a little 'too big and un-tamed' it is almost too late. My father always said, "only cry once." Meaning - if you want a G.I. Joe with kung-fooBAR grip. Don't settle for 10 Malibu Ken dolls with pasted on peach-fuzz beards. Get out your lawn mower and mow a few extra laws, baby sit until you puke, and buy stock in Red Bull. If you only cry once. and pay the price up front you will save untold hours of refactoring bits and pieces to get things working.
About your chart dilemma - consider consolidating like chart types. Generalizing an interface to facilitate repurposing is smart and means that each one of your little chart dudes isn't the size, or greater, of the Flex chart library. Additionally - becoming proficient in primitive drawing could be much more valuable that using 'canned controls.' Take a look http://www.degrafa.com/ add a dash of creative thinking and you could dump charts. come up with a framework for reporting that is boot-licking delicious. Rick Winscot From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Bjorn Schultheiss Sent: Thursday, May 08, 2008 8:56 PM To: [email protected] Subject: [flexcoders] Re: Help with Module strategy - 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 [email protected] <mailto:flexcoders%40yahoogroups.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. >
