Flight Framework: Application Structure

The core of Flight’s methodology is in its prescribed structure. The framework guides the architectural process by establishing package (folder) structure and modularization of code. It helps answer the question, “where does this go?” Though its concepts are simple they are effective in promoting iterative development and code reuse. A common application structure is also important in organizing team development and in creating a familiar development environment.

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.

Flight Framework: Feature List

Following is a list of some major features that make up the Flight Framework.

• 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

Flight Framework: Diagram

download PDF

Flight Framework: Overview

The Flight Framework is an Application Development Framework for developing web and desktop applications in Flash and Flex. The framework prescribes a Model-View-Controller workflow that minimizes the complexity of application development. It modularizes domain logic, streamlines team development, and creates a natural iterative programming environment. Most importantly, Flight Framework is designed to make your day to day coding experience as simple and enjoyable as possible.

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.