Oh, I didn't realize that. I've been able to defer this for now, but clearly I need to do more research. Thanks for the input.
On Fri, May 9, 2008 at 9:00 PM, Bjorn Schultheiss <[EMAIL PROTECTED]> wrote: > Whether the figures are correct or not i don't see how it affects your > modular decision. > > Framework caching will only effect the size of your shell not your > modules. > If your modules are optimized for your shell they will not include the > framework classes used by the shell. > > --- In flexcoders@yahoogroups.com, "Richard Rodseth" <[EMAIL PROTECTED]> > wrote: >> >> After doing a bit of analysis, it doesn't seem that modules are >> appropriate for me, without framework caching. >> >> The monolithic app is currently 539K. An individual module containing >> charts, optimized for the monolithic app is 275K. Optimized for an >> empty app it's 382K. Not optimized, it's 624K. Since 5 or so modules >> will be loaded, the experience is likely to be a step backward, unless >> I can consolidate charts somehow, as Rick alluded to, or enable >> framework caching. >> >> Can someone please confirm or correct the following: >> - Player 9 is around 97% penentration, but 9.0.115 is only around 61% >> - If I enable caching, the app will still work (albeit slowly) on > older players >> - The user won't know to update to 9.0.115 unless I build the app to > require it >> - However, using expressInstall, the upgrade to 9.0.115 would be > seamless >> - [??? any issues around localization ???] >> >> - Richard >> >> On Fri, May 9, 2008 at 6:56 AM, Richard Rodseth <[EMAIL PROTECTED]> wrote: >> > I suppose a broad description would be business >> > intelligence/dashboard/reporting. It's true that for a fixed set of >> > reports or charts the main app swf can be updated and no modules are >> > required, but runtime configuration seems like an inevitable >> > direction. >> > >> > The main wrinkle mentioned in my original post is the desire to >> > extract individual reports as separate entities. Again, the build >> > system could simply build a distinct swf application for each one, so >> > I realize that modules are not absolutely needed. >> > >> > The strategy I describe (same host for 1 or many modules) allows me to >> > defer the RSL/caching stuff and optimize the modules for that single >> > host, but doesn't preclude a switch to portable modules in future. >> > >> > On Fri, May 9, 2008 at 6:17 AM, Rick Winscot <[EMAIL PROTECTED]> wrote: >> >> What exactly is it that you are trying to extenensify? You don't > have to >> >> give up the secret sauce - but with a little more info maybe > ideas will >> >> start to flow? Modules are great for portability and system > extension that >> >> is true... but modules for modules sake of themselves > extensibility do not >> >> make. What's the rubble? >> >> >> >> Rick Winscot >> >> >> >> -----Original Message----- >> >> From: flexcoders@yahoogroups.com > [mailto:[EMAIL PROTECTED] On >> >> Behalf Of Richard Rodseth >> >> Sent: Friday, May 09, 2008 8:57 AM >> >> To: flexcoders@yahoogroups.com >> >> Subject: Re: [flexcoders] Re: Help with Module strategy >> >> >> >> Rick, >> >> >> >> I know about Degrafa and might use it for some gauges, but I've been >> >> pretty happy with Adobe's charting library. I would say that at this >> >> stage my motive for modules is extensibility rather than file size or >> >> even memory usage. >> >> >> >> On Thu, May 8, 2008 at 9: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, "Richard Rodseth" <rrodseth@> > 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. >> >>>> >> >>> >> >>> >> >> >> >> ------------------------------------ >> >> >> >> -- >> >> Flexcoders Mailing List >> >> FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt >> >> Search Archives: >> >> http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! > Groups Links >> >> >> >> >> > >> > >
