--- In flexcoders@yahoogroups.com, "Michael Schmalle" <[EMAIL PROTECTED]> wrote: > > well big mouth has to say one more thing, > > Imagine commitProperties() committing property states :) , all of your > properties have been committed. Children can be created at any time AFTER > super(). > > What you fail to see is commitProperties() is a glorified createChildren(). > This only thing "cool" about createChildren() is Container calls > createComponentDescriptors() which is a heavy method. > > Other than the above, commitProperties() ALWAYS runs before measure () and > updateDisplayList() so there is never a problem with creating children in > commitProperties(). > > But subclassing a UIComponent, give me a break. I was under the impression > from Eric's post that his "issue" was more than just create the children in > create children, why the hell would I tell him to circumvent a template > method!?
You're right that in UIComponent there's not anything that directly addresses children, except as some of the styling code addresses "implicit" children. However, as soon as you start dealing with subclasses, you can't really be so sure. And if he's creating children in his commitProperties(), and then he subclasses commitProperties, he (or any developer who comes after him) absolutely will need to know what specific thing he did in his commitProperties(), because any properties that will affect those children will either need to be set before the super(), if they're carried forward into the new children, or after the super(), if they are depending on the children's having already been created in setting properties on them. If you're creating commercial components, I would think that this would already have occurred to you, because it directly impacts whether you can get away with providing your components without source code. And...createChildren() runs _before_ commitProperties. So I'm thinking that creating the children actually later isn't going to help with a problem caused by the children's not existing when the logic runs on the children. The real problem is that something external to the component seems to be trying to reach in and touch something in a way that the component should be controlling. He didn't specify what the exact architecture is, so neither one of us could give him specific suggestions on how to solve the problem. I don't believe, though, that delaying creation of the child components will help his timing issues. > Sorry, your post felt a little personal. I wrote it myself :-) -Amy
