Re: [flexcoders] Re: Help with Module strategy
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
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 [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. -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [flexcoders] Re: Help with Module strategy
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 [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. -- 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
Re: [flexcoders] Re: Help with Module strategy
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 [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
Re: [flexcoders] Re: Help with Module strategy
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 [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
[flexcoders] Re: Help with Module strategy
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
[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 [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.
RE: [flexcoders] Re: Help with Module strategy
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 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.
Re: [flexcoders] Re: Help with Module strategy
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]
