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 > >> > >> > > >
