At 360|Flex this last month there were 5 different framework-centric presentations, from Adobe’s Cairngorm down to build-your-own-framework. Each framework presents its own virtues and vice’s, each developed to solve their originator’s focused set of organizational problems encountered in their architecture. I’m not an expert in any one of these frameworks and so won’t compare or contrast this list of projects to determine the “best” one. Even better, I have one more to throw on the pile: Flight Framework. Yet another framework, another methodology, another workflow for Flash and Flex application development … why? Why offer another option in the crowd of mulling libraries that vie for popularity?
Flight Framework is, of course, another MVC framework and is not too unfamiliar to Cairngorm or server-side MVC frameworks. In fact it could be compared to Cairngorm but with less “boiler-plate” and more utility. The MVC implementation Flight dictates has been compared to HMVC: Hierarchical-Model-View-Controller. Flight organizes modules of behavior and data into MVC sub-systems called domains. Each domain has a controller class, a business model and all the logic and independence necessary to become a stand-alone system. This just means easier organization of larger systems and built-in reuse of logic between applications. Flight’s domains are supported by a convenient backing of common solutions, such as commands, history, weak-referenced binding and system notifications. Beyond domains, Flight Framework presents application configurations, services, an application package structure and convenient domain access from the view. This is just a broad and abstract summary of Flight Framework; examples and documentation better prove a projects real value.
So why add one more to the lineup? Five different presentations last month demonstrate some dissatisfaction with available solutions. The frameworks were developed in response to needs that were not met. Flight answers my need. It will answer your needs. It’s more prescriptive, better structured and organized, and answers the question “where does this go?” in application development. It’s small, but provides an applications basic needs. It forces definition and strong architectures. It doesn’t care about coupling already-dependent classes, recreating solutions that already exist, or strictly (and complexly) adhering to design patterns for design patterns sake. Flight balances application design with development practicality. It favors use of auto-completion and compile-time error checking over dynamic (aka “manual”) API look-up and run-time errors, and without requiring extra “framework code”. It separates advanced techniques for use only in advanced need. And Flight Framework has been and continues to be developed by active application developers who keep in touch with the Flash and Flex development community.
But most importantly, Flight answers my need. I will be happy building Rich Internet Applications without any popularity to validate the use of the framework. However, Rob Taylor (co-architect/developer) and I are happy to contribute in any way to the development community we’ve received so much from, even if this contribution heightens the “framework” conundrum. I recommend taking a serious evaluation of Flight – I think it’s the solution you’re looking for. Happy searching!
note: Flight Framework will not be released publicly until documentation and examples are complete, both of which are in the works and will be completed soon. We hope you understand the invaluable nature of these resources that will temporarily delay code release.