Re: [flexcoders] Large Flex app architecture
Agreed: I just did a write-up today on the very subject. http://www.mossyblog.com/archives/441.cfm It's got me baffled as to how to fix this as I know for a fact at work killing a browser and what not just won't be done on most cases for long periods: I mean if were to use a Kiosk style approach to allow folks in board-rooms and what not to initiate actions, thats an environment where browser refreshes will occur every now and then. We also make use of large Smartboards (picture really big touch-screen but works like a whiteboard) at work and well, they often sometimes keep the one browser open a lot aswell - well could be the case anyway. Can we get some salvation from a Flash/FLEX Engineer please ;) On Apr 3, 2005 1:00 PM, Jose Lora [EMAIL PROTECTED] wrote: We also have a quite large internal application (Campaign Management) and we're using a very similar approach with an event driven Form factory and a main ViewStack. 90% of the code is based on custom views. We started with the Cairgorm framework, but we have to add some additional artifacts and extend their model to allow things like multiple commands listening to single events (believe me, we need this), generic data services and generic commands to handle multiple similar views. Our factory has also the job of destroying views (and related models, command instances and helpers). We've been very careful trying to destroy every piece of non use memory to avoid issues, however, after some days of use (if the user doesn't reload the app) the application will stop responding and we'll have to kill the browser. That makes me think that there could be some issues with player garbage collection. From: Scott Barnes [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 30, 2005 7:02 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Large Flex app architecture I too am in the same boat and have thought / researched on this very subject. I'm attacking my FLEX archiecture much in the same way i would with a traditional web paged system. I've looked at Screen by Screen approach where typically you active a screen for a task. Example: TravelAuthorization Request Form (Wizard Format) = Screen1 TravelAUthorization Admin Form = Screen 2 TravelAuthorization Summary / Report = Screen 3 etc.. Now each of these screens have their own sub-screen lifecycle (ie much like the FlexStore where checkout form replaces product pod and so on). Anything that significantly breaks away from a parent Screen becomes a screen onto itself. Once I formulated a pattern for this and broke my approach into screen by screen, I am then going to use a destroy / create approach. I'm hoping that my theory holds that Flash Garbage collection will free up memory every time i destroy a screen, but this is a Intranet Application so bandwidth isn't my top priority here (while i should be mindful of it) - so I plan to use Run Time Shared Libraries but will quite happilly kill an asset and move it to a download every bite situation if need be. I will use view stacks up until a point, and then i'll have my own quasi view stack manager to attack the same problem. Again, I am not finding much information on how FLEX Garbage collection works and what key tricks i need to make sure are in place, so the above may not hold water and won't know until I have it fully tested and working but surely a destroy/create approach should work and if it doesn't by god MM you better make it happen soon or i'll...i'lll bah..i got nothing. hehe. I posted on my blog on how I am attacking this screen by screen approach, via this: http://www.mossyblog.com/archives/434.cfm Its a framework I am working on and its ripped off a few concepts from Mach-II and Apache Cocoon. On Wed, 30 Mar 2005 09:08:40 -0800 (PST), Valy Sivec [EMAIL PROTECTED] wrote: I'm designing a quite large application and plann to use viewstack container(s). Because each view will contain lots of panels and info I'm affraid that the browser might hit his limit in regards with the memory consumption and crash... seen couple of messages with the same problem and I would like to avoid it... Actually I'm not even sure how the Flash Player garbage collector works or if there is any I'm very new to this Flash/Flex world so sorry if the question is dumb... Is it safe grouping the screens in multiple viewstacks and include them from the jsp pages? or should be enough having only one viewstack container for the whole application? Any suggestion? Valy Do you Yahoo!? Make Yahoo! your home page Yahoo! Groups Sponsor ADVERTISEMENT Yahoo
RE: [flexcoders] Large Flex app architecture
We also have a quite large internal application (Campaign Management) and were using a very similar approach with an event driven Form factory and a main ViewStack. 90% of the code is based on custom views. We started with the Cairgorm framework, but we have to add some additional artifacts and extend their model to allow things like multiple commands listening to single events (believe me, we need this), generic data services and generic commands to handle multiple similar views. Our factory has also the job of destroying views (and related models, command instances and helpers). Weve been very careful trying to destroy every piece of non use memory to avoid issues, however, after some days of use (if the user doesnt reload the app) the application will stop responding and well have to kill the browser. That makes me think that there could be some issues with player garbage collection. From: Scott Barnes [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 30, 2005 7:02 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Large Flex app architecture I too am in the same boat and have thought / researched on this very subject. I'm attacking my FLEX archiecture much in the same way i would with a traditional web paged system. I've looked at Screen by Screen approach where typically you active a screen for a task. Example: TravelAuthorization Request Form (Wizard Format) = Screen1 TravelAUthorization Admin Form = Screen 2 TravelAuthorization Summary / Report = Screen 3 etc.. Now each of these screens have their own sub-screen lifecycle (ie much like the FlexStore where checkout form replaces product pod and so on). Anything that significantly breaks away from a parent Screen becomes a screen onto itself. Once I formulated a pattern for this and broke my approach into screen by screen, I am then going to use a destroy / create approach. I'm hoping that my theory holds that Flash Garbage collection will free up memory every time i destroy a screen, but this is a Intranet Application so bandwidth isn't my top priority here (while i should be mindful of it) - so I plan to use Run Time Shared Libraries but will quite happilly kill an asset and move it to a download every bite situation if need be. I will use view stacks up until a point, and then i'll have my own quasi view stack manager to attack the same problem. Again, I am not finding much information on how FLEX Garbage collection works and what key tricks i need to make sure are in place, so the above may not hold water and won't know until I have it fully tested and working but surely a destroy/create approach should work and if it doesn't by god MM you better make it happen soon or i'll...i'lll bah..i got nothing. hehe. I posted on my blog on how I am attacking this screen by screen approach, via this: http://www.mossyblog.com/archives/434.cfm Its a framework I am working on and its ripped off a few concepts from Mach-II and Apache Cocoon. On Wed, 30 Mar 2005 09:08:40 -0800 (PST), Valy Sivec [EMAIL PROTECTED] wrote: I'm designing a quite large application and plann to use viewstack container(s). Because each view will contain lots of panels and info I'm affraid that the browser might hit his limit in regards with the memory consumption and crash... seen couple of messages with the same problem and I would like to avoid it... Actually I'm not even sure how the Flash Player garbage collector works or if there is any I'm very new to this Flash/Flex world so sorry if the question is dumb... Is it safe grouping the screens in multiple viewstacks and include them from the jsp pages? or should be enough having only one viewstack container for the whole application? Any suggestion? Valy Do you Yahoo!? Make Yahoo! your home page Yahoo! Groups Sponsor ADVERTISEMENT Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. -- Regards, Scott Barnes http://www.mossyblog.com http://www.flexcoder.com (Coming Soon) Yahoo! Groups Links To visit your group on the web, go to:http://groups.yahoo.com/group/flexcoders/ To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Re: [flexcoders] Large Flex app architecture
I too am in the same boat and have thought / researched on this very subject. I'm attacking my FLEX archiecture much in the same way i would with a traditional web paged system. I've looked at Screen by Screen approach where typically you active a screen for a task. Example: TravelAuthorization Request Form (Wizard Format) = Screen1 TravelAUthorization Admin Form = Screen 2 TravelAuthorization Summary / Report = Screen 3 etc.. Now each of these screens have their own sub-screen lifecycle (ie much like the FlexStore where checkout form replaces product pod and so on). Anything that significantly breaks away from a parent Screen becomes a screen onto itself. Once I formulated a pattern for this and broke my approach into screen by screen, I am then going to use a destroy / create approach. I'm hoping that my theory holds that Flash Garbage collection will free up memory every time i destroy a screen, but this is a Intranet Application so bandwidth isn't my top priority here (while i should be mindful of it) - so I plan to use Run Time Shared Libraries but will quite happilly kill an asset and move it to a download every bite situation if need be. I will use view stacks up until a point, and then i'll have my own quasi view stack manager to attack the same problem. Again, I am not finding much information on how FLEX Garbage collection works and what key tricks i need to make sure are in place, so the above may not hold water and won't know until I have it fully tested and working but surely a destroy/create approach should work and if it doesn't by god MM you better make it happen soon or i'll...i'lll bah..i got nothing. hehe. I posted on my blog on how I am attacking this screen by screen approach, via this: http://www.mossyblog.com/archives/434.cfm Its a framework I am working on and its ripped off a few concepts from Mach-II and Apache Cocoon. On Wed, 30 Mar 2005 09:08:40 -0800 (PST), Valy Sivec [EMAIL PROTECTED] wrote: I'm designing a quite large application and plann to use viewstack container(s). Because each view will contain lots of panels and info I'm affraid that the browser might hit his limit in regards with the memory consumption and crash... seen couple of messages with the same problem and I would like to avoid it... Actually I'm not even sure how the Flash Player garbage collector works or if there is any I'm very new to this Flash/Flex world so sorry if the question is dumb... Is it safe grouping the screens in multiple viewstacks and include them from the jsp pages? or should be enough having only one viewstack container for the whole application? Any suggestion? Valy Do you Yahoo!? Make Yahoo! your home page Yahoo! Groups Sponsor ADVERTISEMENT Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. -- Regards, Scott Barnes http://www.mossyblog.com http://www.flexcoder.com (Coming Soon) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * 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/
