Flexcairngorm extensions considered

Tracing the evolution of the Cairngorm framework reveals a great effort to isolate business logic. A coup of the framework has been to shift event flow from exclusively the display list towards a simple, efficient non-UIComponent propagation within an application architecture.

Specifically, the native event flow in Flex works hierarchically within the display list. Since display objects are by definition hierarchical, events flow through them from impetus to the bottom node and, if so configured, back again. This ensures full propagation of the event. A reasonable supposition on behalf of Cairngorm engineers is the difficulty of performing business logic apropos of a display hierarchy. Business logic requires a unique non-display set of delegates, services and model managers. The Cairngorm framework places events at the behest of these classes.

How then to bridge the new events and the old? This is where flexcairngorm takes the reins.

There is a very handy explanation of this, supplemental graphics and all, by Thomas Burleson on Gridlinked.info. He describes the process by which notification returns to the view following the propagation to business logic and the response back. It involves IResponders and a callback parameter. Browse gridlinked.info to learn all about it.

Once you've read it, the next step is coordinating flexcairngorm with Mate dependency injectors, using Mate EventMaps.