Not sure the best title, but close enough. You cannot have faceless children be involved in the event bubbling phase for event propagation to fire off Commands via the FrontController. The solution is to have them extend a DisplayObject of some sort, typically UIComponent.
Why? A few reasons.
To define faceless children, they are class instances that do not extend a DisplayObject; something that has ties to the DisplayList and thus can be visible. An Object can’t be a seen, but a Sprite can for example. You can define class instances or MXML tags within View components as children of that component / class. If they do not extend a DisplayObject, to me, they are defined as faceless children.
Event bubbling is referring to how, when a event is dispatched from a deeply nested view, it’ll go up the DisplayList in a vertical fashion, like a squirrel climbing down a branch of a tree to the trunk (only he’s going down… you get the gist). He doesn’t go side-ways to other branches, but rather keeps going to the parent of the braches. Event bubbling is similar. If you dispatch an event with bubbling to true, it’ll do this. This is a great feature.
It’s also considered rude to do this and bad practice. Another View could have an event of the same name (since event types are still just Strings), and you could inadvertently fire something further up the chain that didn’t ever think of canceling events.
The justifiable times are when you want a deeply nested View to fire off a Command in Cairngorm 2. In Cairngorm 1, you’d use a special class to do this, EventBroadcaster. This has been ditched in Flex 2 for the, now intrinsic, EventDispatcher class. Cairngorm events are indistinguishable from regular events. The FrontController determines what fires off a Command. This is nice and has good performance gains.
However, it implies that only UIComponents can fire off Commands. Purists may irk at this, but whatever. MXML at least makes this really transparent. If I do
Now, granted, you could manually capture the events in the View that hosts these faceless children, and then forward on the event… but um… dude, we have bubbling. Again, one could argue the performance overhead of extending a visual object merely for the sake of preventing writing 3 lines of additional code. :: shrugs :: To each their own.
Bottom line, if your class merely extends EventDispatcher, and dispatches a bubbling event with the intent of firing off a Cairngorm Command via the FrontController, it won’t work. If you make it extend UIComponent, it will.