Re: [flexcoders] JUST SAY NO to creationPolicy="all" !

[John Kirby]

Title: quote

Gordon - Good comments.   Your first statement is correct. My "subSWFs" are applications composed of Charts/Reports which the user may or may not use and a Flex--> Flash of Yahoo maps which the user might never use. So what you are saying makes sense... defer the swf loading via removing creationPolicy='all'. There's a book somewhere here on best practices and performance/tuning to address issues like this.  As a Flex neophite I'm a little concerned that an enterprise Flex application can quickly get "out of hand" by being  too "bloated" from a lack of understanding.  Understanding more of the "inards" of Flex helps with the design. Hopefully as Flex matures Adobe will start addressing some of the best practices. .j Gordon Smith said the following: I'm not clear on what you're doing. It sounds like you have two panes in which the only child is a SWFLoader, and you're setting creationPolicy="all" in order to get these loaders to load their subSWFs at startup.   To me that sounds like a lot of stuff happening at startup, which wouldn't scale well if you had a lot of panes doing this. Assuming these subSWFs are <mx:Application>s, they have a lot of the same framework code as your main app. So you're downloading a lot more over the wire at startup than if everything was in a single main SWF with deferred instantiation. And the player is having to create a lot of invisible DisplayObjects for the panes that haven't been navigated to.   I'm not an expert on loading sub-applications into a main application, but I don't think this generally pays off unless you delay the loading until the user navigates to the appropriate part of the app. The question of whether the creation of the SWFLoader itself should be deferred is less important, but I see no reason not to.   When I wrote "complications" I was just thinking of relatively minor things like having to build multiple SWFs and having to include the "content" property when you "dot down" to access something in those panes from the main app. We've also had a fair number of framework bugs that turn up only when you load an app into another app, although I think we've fixed most of those that we're aware of.   - Gordon   From: [EMAIL PROTECTED]ups.com [mailto:[EMAIL PROTECTED]ups.com] On Behalf Of John Kirby Sent: Monday, October 30, 2006 4:18 PM To: [EMAIL PROTECTED]ups.com Subject: Re: [flexcoders] JUST SAY NO to creationPolicy="all" !   Can you give me an example of "complications"?  For example I have 6 tabs in my application.   Two of the tabs load SWF files.  So in this case a user may never select the tab which loads a swf.  Is this a case to say no to creationpolicy=all? Gordon Smith said the following: Yes, but that introduces more complications, so I'd tend to go that route only on a very large app where the user may never navigate to some functionality.   - Gordon   From: [EMAIL PROTECTED]ups.com [mailto:[EMAIL PROTECTED]ups.com] On Behalf Of John Kirby Sent: Monday, October 30, 2006 3:05 PM To: [EMAIL PROTECTED]ups.com Cc: Matt Horn Subject: Re: [flexcoders] JUST SAY NO to creationPolicy="all" !   Gordon - Good advice.   I also assume that there are even greater savings (load time) if one of these controls uses a SWF loader? Gordon Smith said the following: <rant>   Several times a week someone complains that they can't seem to set data into controls on the second, third, etc. pane of a ViewStack, Accordion, or TabNavigator because these controls don't get created until the user navigates to the pane they're on.   Inevitably there are multiple replies "solving" this problem by setting creationPolicy="all". Inevitably I reply that Adobe doesn't recommend doing this because it defeats the entire purpose of the deferred instantiation feature, which is to minimize startup time by not creating visual components until they need to be seen.   A much better technique is to use event handlers to get the appropriate data into the controls after they get created. For example, you can use the 'initialize' event on each pane, which won't get dispatched until after that pane's controls exist.               <mx:Accordion>                         <mx:VBox initialize="textInput1.text='Hello'">                                     <mx:TextInput id="textInput1"/>                         </mx:VBox>                         <mx:VBox initialize="textInput2.text='World'">                                     <mx:TextInput id="textInput2"/>                         </mx:VBox>             </mx:Accordion>   Using databinding is another good technique. The bindings will occur after the controls get created.   I've never seen a case where it is necessary to push data into the controls before they exist. If you must put the data somewhere in the meantime, store it in data vars, which have none of the startup cost of a visual component, and then move it into the controls after they get created.   </rant>   - Gordon, the Flex framework engineer who designed and implemented the deferred instantiation feature, so listen to me on this one!     -- Whether you think that you can, or that you can't, you are usually right.  - Henry Ford   -- Whether you think that you can, or that you can't, you are usually right.  - Henry Ford -- Whether you think that you can, or that you can't, you are usually right.  - Henry Ford __._,_.___ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Software development tool Software development Software development services Home design software Software development company Your email settings: Individual Email|Traditional Change settings via the Web (Yahoo! ID required) Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe __,_._,___