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.
Hi Jester,
the latest version of cairngorm reintroduces the EventBroadcaster, it is called CairngormEventDispatcher now. See Alex’ posting about Cairngorm 2: http://weblogs.macromedia.com/auhlmann/archives/2006/07/cairngorm_2_for.cfm
Cheers,
Ralf.
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.
Hey,
We have just started a flexforum at http://www.flexforum.org. We will do the best to answer all questions. Just wanted to tell. It would be fun to have a good forum for all us flexlovers =) Please join!
All the best
Mattias
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.
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.
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.