" 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"
I love it! On Fri, May 9, 2008 at 2:10 PM, Rick Winscot <[EMAIL PROTECTED]> wrote: > 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:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On > Behalf Of *Bjorn Schultheiss > *Sent:* Thursday, May 08, 2008 8:56 PM > *To:* flexcoders@yahoogroups.com > *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 flexcoders@yahoogroups.com <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. > > > > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
