The Flex object composition car example I recently created got some updates. I changed CompositionBase into a interface instead inheriting the class (thx Marcus for the heads up on that one). I also went through all the code and

…

This is just an idea I had while looking through the source code.
All your car parts extend from the ‘CompositionBase’ class to ensure that the ‘ptrCar’ property is available to be set from the ‘Car’ class by its childrenCreated() method. In this example, that’s cool and works fine, but I’d suggest you create an ‘CompositionBase’ Interface that all your car parts can implement, rather than the ‘CompositionBase’ Class they extend. (AS3 allows you to define getters and setters on Interfaces now.) That way you still know all the car parts implement the ‘ptrCar’ thingy and they have the freedom to extend from other more relevant classes. eg. Headlight.as, Blinker.as, InteriorLight.as, GloveBoxLight.as can all extend from a basic Light.as Class to get its on/off functionality as well as implement ‘CompositionBase’ so we know they all belong to our car.
Keep up the good work.

http://www.onflex.org/ACDS/BuildingAFlexComponent.pdf

He states the life cycle of the component (page 8) is as such:
Constructor
createChildren()
commitProperties()
measure()
updateDisplayList()
CustomEvents

I am a little new to all this also, so my thinking is that
creationComplete event’s definition is this

“Dispatched when the component has finished its construction, property processing, measuring, layout, and drawing.”

This puts the creationComplete event in at the tail end of the component lifecycle. Now for childrenCreated()’s definition:

“Performs any final processing after child objects are created.”

Now I should do some real tests but it makes sense to do your initializing of pointers etc… right after the children are created (either createChildren() as in Ely’s slide or childrenCreated()) so that the initialized code can be used in the rest of the Child’s lifecycle, (commitProperties(), measure(), updateDisplayList(), Custom events)

Both methods will work its a matter of the lifecycle of the component and what you want to accomplish.

But anyway, I’m curious why you think it’s more proper for a custom component to use the override approach rather than the event listener approach?