>> >> Removed initModel and initSkin methods. The lifecycle is now much >simpler: instantiate, set properties and beads then add to the display >list. We're still using child.addToParent(parent), but I am going to >experiment next with changing over to parent.addElement(child). > >Any particular reason why? I was beginning to get a hang of the >child.addToParent() way.
The short answer: to reduce migration pain. My internal customer showed me a bunch of code with a lot of addElement() calls in it. The long answer: I was looking at how addToParent() is currently implemented and found that I couldn't completely remember why I felt it was a better strategy. Current Flex has tried two approaches so far, the main issue being: how do you manage children in a container? The two approaches: 1) addChild + rawChildren.addChild 2) addElement goes to contentGroup (and block addChild) The choice for FlexJS is mainly about how to do it on the JS side. We could use one of these two strategies, or use addToParent() or even go with the HTML/JS appendChild/insertChild, or something else. I'm actually quite undecided at this point, which is why I hope the experiment will help finalize the decision. So far, I've had the following thoughts: A) wrapping addChild messed up a lot of low-level tools like display list tree walkers used in Spy-like programs. I'm leaning against wrapping addChild again. B) addToParent requires that the child have some knowledge about the parent. Maybe it is better for the parent to have some knowledge about the child. C) addToParent worked well for simple control composition, but when I ended up having to abstract out the actual parent when managing container children on the AS side I ended up with an "internal" addChild contract anyway. Opinions and contributions always welcome, -Alex
