Though Flight wasn’t in the public eye at the time, it has finally caught up. Tony hasn’t yet reviewed the framework, but the twitter client known as TwitteRIA is now available as a Flight application. It’s a good example app and nice for comparing Flight with your favorite framework. The source is here.

Enjoy!

Download the SWC or check out the source at Google Code.

NOTE: the diagram also establishes the following package structure

Package Structure

An application should have a root package named after the application. If you don’t have a real name for your app give it a code name. Clear and descriptive naming helps you dig down through your folders to locate code quickly. This initial package can follow any naming convention you’re comfortable with, such as com.flightxd.superhero, or just superhero.

The application contains these 3 packages:

(application)

• config - holds all of the applications configurations
• domains - contains one or more domain package, the real logic of the app
• view - all of the user interface logic specific to the app

The config package is flat and just holds ActionScript and MXML files. The view package usually starts out flat when the user interface is sparse but should be organized with additional packages once complexity increases. Divide up your application components by their function in the system, not by their type, style or layout. For example, the EditHeroScreen class would reside in the view.herobuilder package and not in a view.screens package.

The domains package holds any number of developer-defined packages which each contain a specific set of Flight-defined packages. These “domain” packages should also have descriptive names reflecting the logic they embody. For example, a domain that deals with all the details and logic of a super hero’s power could be called superpower.

Each domain package structure is defined:

(domain)

• commands - all commands used by the controller
• model - all of the underlying data and logic for a particular domain
• view - optionally defined for portable components tied to a domain
• (DomainController) - this class represents the public API to a domain

Defined commands are named after their action. Because no other type of class is named by a verb, commands are easy to identify and do not require a trailing “Command”. For example, the action “lift off” can be named LiftOff rather than LiftOffCommand. More on commands and models are discussed later on.

Each domain has a public class which extends DomainController. This class acts as an entry point and a manager to the domain and is named in a like manner after the domain. For example, if the domain package was named domains.superpower then the DomainController class would be named SuperPowerDomain. Domains and their function in the application are an important part of Flight and are described in greater detail later on.

These guidelines define a template for all Flight applications and libraries. By following the prescribed structure of the Flight Framework developers will enjoy a consistent and straightforward approach to application organization.

• ActionScript 3, Flash Player 9 on up
• Configurations, including sources of XML, url, FlashVars
• Common package structure
• Feature-driven workflow
• Team development
• Modular Model-View-Controller
• Flex, AIR and Flash friendly
• Weak-reference binding
• Simple and straightforward methodology
• Transaction Scripts and Commands
• Asynchronous workflow
• Queues and sequencing
• MXML and ActionScript ready
• Undo, redo and history keeping
• Object editing workflow
• Cool logo
• Support for a robust domain model
• Data formatting
• Small and fast
• Enjoyable to code with

download PDF

What it is:

• available source code
• SWC (compressed library) for download
• powerful library
• final home
• a start

What it isn’t:

• documented
• feature complete
• thoroughly tested
• community driven … yet

And it’s for this last reason that the framework is being released without thorough documentation and testing. We hope to get your feedback and involvement as we continue to grow and develop the project. This website will remain the project’s primary resource for documentation and info, while Google Code handles the project code, and a Google Group to take care of the community.

Approach

Flight is a minimalist. Everything from its size to its prescribed processes ensure that you never have to do more than is absolutely needed. But it’s not a skeleton of interfaces either, offering robust solutions such as built-in undo/redo and custom process queues. And Flight was designed to be extended, built on interfaces and abstract classes, and offering ready-made plugin capabilities on your own libraries.

Methodology

The Flight Framework prescribes a common structure and methodology that can be leveraged throughout all tiers of your application. By understanding its basic principles you will gain command over the development of your applications, libraries, and those built by others using the framework. Flight takes a modular approach to the widely adopted Model-View-Controller as its basis of organization.

Domains

A Flight application is made up of a series of one or more MVC modules, or domains. Each domain under Flight represents a specific business domain, or a real-world set of related problems and solutions. Domain examples are infinite and range anywhere from a user account to an entire shopping cart, from an application’s screen flow to a full image-editing library. These MVC subsystems are defined by you, reflecting your application goals, and are unique to their specific purposes. Some domains are completely self-contained and are reused across many projects, while others have dependencies among each other or the application. Domains can even be organized hierarchically, a high-level domain wrapping a group of sub-domains, for greater modularization and manageability of a complex system. Though a powerful tool, domains are simple enough and easy to approach in development. In Flight, well-defined domains will be the strength of your application development.

Flight Framework maintains an emphasis on supporting capable clients: Flex and Flash applications that are much more than just a pretty face to a server implementation. Through features like domains (modular MVC systems) and a prescribed structure, the framework transforms component scripting into real application development.

We are finally launching the Flight Framework as an opensource project under the MIT license. The project is in beta and will likely undergo some minimal changes based on user feedback.

Welcome to the Flight Framework project.