Flex Chronicles #21: Faceless Children in Cairngorm 2

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 , you can’t immediately tell what it’ll look like visually compared to for example. As long as she extends UIComponent, it’ll work just fine since that’s pretty much a requirement for being put in a UIComponent; you must also be a UIComponent.

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.

6 Replies to “Flex Chronicles #21: Faceless Children in Cairngorm 2”

  1. Yeah, picked this up on MXNA this morning. At the time of this writing, I’m using the beta 3 build that Cairngorm 2 was made for. Hrm… I agree with their reasonaing, though. Coupling to DisplayObject’s only really gained you performance benefits, and most people aren’t intending to cancel events propgated with the intent to fire off commands anyway. It’s nice too, because it’s more explicit what you are doing. With strong-typing, I doubt the performance is that big of a deal either.

  2. The reason they reintroduced the EventBroadcaster is because they were using the mx.core.Application.application to dispatch events to the FrontController which didn’t work for popups… it looked like this
    Stage
    |
    System Manager
    | |
    Application Popup

    You can see why dispatching an event form a popup wouldn’t work.. it never makes it to the Application object and since the FrontController was listening only to the Application the event wasn’t being picked up.

    Reintroducing the CairngormEventDispatcher as a central event pipe that everything dispatches to and the Controller listens on… eliminates this problem.

  3. Darron already posted a solution to that problem. To me, popups were too much of an edge case to really justify this as a big problem, but better to make standards that work for everyone than having to workaround some weird reason.

  4. Hi,

    I was bored the other day and decided that I wanted to play around with the Freestyle XL application. After searching through my drive I found that I no longer had it. No problem, I’ll just download it again from Jesse’s site. Hmm… no longer there. No problem, I’ll just google for it. What…. no one has it!!

    Is there a reason for this? Are you ‘pulling’ it from the shelves? If I’m just trippin’, I apologize and would appreciate a link or a way to redownload your fine app.

    Thanks.

Comments are closed.