RE: [flexcoders] Why you shouldn't set creationPolicy=all to solve your deferred instantiation problems
Gordon, The reason why I normally set creation policy to all is to work around flex bugs. Two of them this week: Repeater in a VBox in a view stack. Layout gets messed up on auto, but seems to draw a bit more properly with an all. ViewStack in a ViewStack, the outer view stack cant see all of the inner view stacks children. Sure, I want things to run fast, but when strange rendering bugs and undefined elements get in the way of getting something done, setting creation policy to all is a common work around. Best, allen From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Smith Sent: 13 October 2005 21:56 To: flexcoders@yahoogroups.com Cc: Flex IMD Subject: [flexcoders] Why you shouldn't set creationPolicy=all to solve your deferred instantiation problems On the accordion tag, set creationPolicy=all. Setting a creationPolicy=All on the accordian container will cause all of the children to be created when the accordian is created. In my post two days ago I tried to explain why setting creationPolicy=all is not The Right Way to solve problems caused by deferred instantiation. I'll try to work with our doc folks to do a better job of explaining the right technique in the future. In the meantime, here's a repeat of what I wrote then. - Gordon I'd like to suggest that it's better to learn how to make deferred instantiation your friend than to simply turn it off. The point of deferred instantiation is to not waste time at app startup creating controls that you don't need yet. If you had a ViewStack with 500 views, it probably wouldn't be a good idea to create the controls on all 500 of them at startup, when only one view is initially visible. The only good reason to set creationPolicy=all, and therefore increase startup time, is to decrease the small navigation delays when you switch from view to view. If these delays are acceptable, then you should allow the views to do deferred creation of their controls, as they were designed to do. So how do you set the initial state of controls that undergo deferred instantiation? You use the appropriate events to set their state AFTER they have been created. For example, you could use 'initialize' or 'creationComplete' events on the the controls themselves. Or you could use events like 'childrenCreated' or 'childrenCreationComplete' on the view that you navigated to. Once you realize that every control in the app doesn't get created at startup, it's always possible -- and not difficult -- to design your app so that you don't push information prematurely into controls that don't exist yet. Instead, it's typical to store information into a data model of some kind that is independent of the controls that display that information. When the controls get created, they pull the information in from the data model. From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Gordon Smith Sent: Thursday, October 13, 2005 12:57 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Any explanation as to why this would happen(Question about accordions) This is due to a feature of Flex known as Deferred Instantiation. My post on Tuesday entitled Re: Unable to refer controls in Accordion ! addressed the issue. - Gordon From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 13, 2005 11:42 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Any explanation as to why this would happen(Question about accordions) I am having some problems getting a button on one panel of an accordion to change the textinput box on another panel of an accordion and I was wondering if someone can give me some idea as to what could be causing this? -- 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 Web site design development Computer software development Software design and development Macromedia flex Software development best practice YAHOO! GROUPS LINKS Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.14/131 - Release Date: 12/10/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version:
RE: [flexcoders] Why you shouldn't set creationPolicy=all to solve your deferred instantiation problems
Can you post some pared-down code that illustrates these two bugs? Maybe we can fix them in the next version. - Gordon From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Allen Manning Sent: Friday, October 14, 2005 2:14 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Why you shouldn't set creationPolicy=all to solve your deferred instantiation problems Gordon, The reason why I normally set creation policy to all is to work around flex bugs. Two of them this week: Repeater in a VBox in a view stack. Layout gets messed up on auto, but seems to draw a bit more properly with an all. ViewStack in a ViewStack, the outer view stack cant see all of the inner view stacks children. Sure, I want things to run fast, but when strange rendering bugs and undefined elements get in the way of getting something done, setting creation policy to all is a common work around. Best, allen From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Gordon Smith Sent: 13 October 2005 21:56 To: flexcoders@yahoogroups.com Cc: Flex IMD Subject: [flexcoders] Why you shouldn't set creationPolicy=all to solve your deferred instantiation problems On the accordion tag, set creationPolicy=all. Setting a creationPolicy=All on the accordian container will cause all of the children to be created when the accordian is created. In my post two days ago I tried to explain why setting creationPolicy=all is not The Right Way to solve problems caused by deferred instantiation. I'll try to work with our doc folks to do a better job of explaining the right technique in the future. In the meantime, here's a repeat of what I wrote then. - Gordon I'd like to suggest that it's better to learn how to make deferred instantiation your friend than to simply turn it off. The point of deferred instantiation is to not waste time at app startup creating controls that you don't need yet. If you had a ViewStack with 500 views, it probably wouldn't be a good idea to create the controls on all 500 of them at startup, when only one view is initially visible. The only good reason to set creationPolicy=all, and therefore increase startup time, is to decrease the small navigation delays when you switch from view to view. If these delays are acceptable, then you should allow the views to do deferred creation of their controls, as they were designed to do. So how do you set the initial state of controls that undergo deferred instantiation? You use the appropriate events to set their state AFTER they have been created. For example, you could use 'initialize' or 'creationComplete' events on the the controls themselves. Or you could use events like 'childrenCreated' or 'childrenCreationComplete' on the view that you navigated to. Once you realize that every control in the app doesn't get created at startup, it's always possible -- and not difficult -- to design your app so that you don't push information prematurely into controls that don't exist yet. Instead, it's typical to store information into a data model of some kind that is independent of the controls that display that information. When the controls get created, they pull the information in from the data model. From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Gordon Smith Sent: Thursday, October 13, 2005 12:57 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Any explanation as to why this would happen(Question about accordions) This is due to a feature of Flex known as Deferred Instantiation. My post on Tuesday entitled Re: Unable to refer controls in Accordion ! addressed the issue. - Gordon From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 13, 2005 11:42 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Any explanation as to why this would happen(Question about accordions) I am having some problems getting a button on one panel of an accordion to change the textinput box on another panel of an accordion and I was wondering if someone can give me some idea as to what could be causing this? -- 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 Web site design development Computer software development Software design and development Macromedia flex Software development best practice YAHOO! GROUPS LINKS Visit your
Re: [flexcoders] Why you shouldn't set creationPolicy=all to solve your deferred instantiation problems
On 10/14/05, Allen Manning [EMAIL PROTECTED] wrote: Repeater in a VBox in a view stack. Layout gets messed up on auto, but seems to draw a bit more properly with an all. Do you have a test case to reproduce this bug? At least we can make sure it doesn't happen in 2.0! ViewStack in a ViewStack, the outer view stack can't see all of the inner view stack's children. _All_ of the inner viewstack's children? Or just the ones that haven't been created? You have to wait until they are created, and the childrenCreated event will tell you when. Yahoo! Groups Sponsor ~-- Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/nhFolB/TM ~- -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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/
RE: [flexcoders] Why you shouldn't set creationPolicy=all to solve your deferred instantiation problems
I'll try and get some simple test cases together. Thanks, allen -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Manish Jethani Sent: 14 October 2005 17:24 To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Why you shouldn't set creationPolicy=all to solve your deferred instantiation problems On 10/14/05, Allen Manning [EMAIL PROTECTED] wrote: Repeater in a VBox in a view stack. Layout gets messed up on auto, but seems to draw a bit more properly with an all. Do you have a test case to reproduce this bug? At least we can make sure it doesn't happen in 2.0! ViewStack in a ViewStack, the outer view stack can't see all of the inner view stack's children. _All_ of the inner viewstack's children? Or just the ones that haven't been created? You have to wait until they are created, and the childrenCreated event will tell you when. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.14/131 - Release Date: 12/10/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.14/131 - Release Date: 12/10/2005 Yahoo! Groups Sponsor ~-- Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/nhFolB/TM ~- -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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/
