I know I shouldn't step in here, but I'd like to ask for a cease-fire. Faithful Flex developers may know that Amy was the guinea pig for Gordon and my first article in Flex Authority magazine where we discussed the component lifecycle at length. It makes me happy to see that Amy has absorbed the ins and outs of the lifecycle and is now one of our top evangelists for how to use it. Michael has been providing expert advice on this forum for quite a while now, and I have seldom seen technical errors in his postings.
The lifecycle is a set of rules and there are exceptions to every rule. I would bet that Michael has figured out where he can bend the rules successfully and isn't just being lucky, but others of you may want to just follow the rules. The original poster and others are encouraged to get their hands on a copy of Flex Authority and familiarize themselves with the lifecycle. Personally, I use createChildren to create any children I know I'm going to need. Everything else is created later depending on when I know enough about which ones and how many to make. ItemRenderers are created as late as updateDisplayList because that's when we know how many we need. -Alex From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Amy Sent: Thursday, October 30, 2008 11:38 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: UI component, a set function & creationComplete --- In flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>, "Michael Schmalle" <[EMAIL PROTECTED]> wrote: > > Amy, > I have read all that you have written. 2 years of sales, no complaints on > the algorithm I use. > > > So it very much matters where you create children when _other people_ are > going to be subclassing your work. > > I have created a sub template in commitProperties(); That can > be overridden from any subclass since it separates operations into hooks. > > 1. > > public function set titleBarRenderer(value:IFactory):void > { > if (_titleBarRenderer != value) > { > _titleBarRenderer = value; > titleBarRendererChanged = true; > invalidateProperties(); > dispatchEvent(new Event("titleBarRendererChanged")); > } > } This is working with a child that may change over time. So right there, this is something that needs _more_ than createChildren(). However, I think in most places where this kind of behavior is needed in the Framework code, a default version of the child is created in createChildren() so it is available for subclasses to work with in commitProperties(). There's an implicit assumption on the part of most developers that all components have been created before commitProperties() is called, and by not having a child available the _first_ time commitProperties runs, you may have a developer doing what he thinks is right and stumbling over your logic. > 2. > > override public function commitProperties():void > { > super.commitProperties(); > > if (titleBarRendererChanged) > { > commitTitleBarRenderer(); > titleBarRendererChanged = false; > } > } And all you need to break this is some developer overriding your code like this: override public function commitProperties():void { if (_styleChanged) { _titleBar.setStyle('color', 0xFFFFFF); } super.commitProperties(); } > 3. > > protected function commitTitleBarRenderer():void > { > createTitleBar(); > } > > 4. > > protected function createTitleBar():void > { > _titleBar = PartFactory.createComponentPart( > TITLE_BAR_NAME, this, rawChildren, > DisplayObject(_titleBar)); > } > > 5. > > tk_internal function partAdded(name:String, instance:Object):void > { > if (instance == _titleBar ) > { > .... configuration > } > } > > As far as not releasing code, this next iteration of products will have > source code, but the template is still the same. > > I hear you on the "I listen to respected developers on this list" but, this > way works even better than how the framework is set up (for subclassing). ...yeah. ;-) > Adds more method calls but, it's impact is irrelevant since these calls are > not 100 every minute. I also use this template for other properties that are > not processor intensive or called to frequently. So far, you've been lucky. Either the developers who use your components are familiar enough with the right way that they haven't broken anything, or they're too new to be messing where they shouldn't. All you need is one intermediate developer charging through the middle of your code, and you'll have a problem. And, to get back to the OP, it's clear he was looking for guidance in best practices. You and I may disagree on when it's ok to bend or break the rules, but when someone _doesn't_ know the rules, it's probably better not to jump him to the bending/breaking stage. -Amy
