Export to GitHub

thin-red-line - FAQ.wiki


Introduction

This is a simplified version of a complex Flex application

Questions


1. Why did I split the project into 5 separate projects?

Everything could be in one project. But I wanted to be able to reuse some of the code for different projects. * FlexFramework contains the extension of the Cairngorm framework. Makes no assumptions about the final application. * FlexSystem contains a couple of helper classes that help managing a Flex application. Makes no assumptions about the final application. * DemoSkins contains skin classes used by CSS * DemoAssets contains no code, just the resources * DemoApp contains the main code of the application


2. Is it possible to split the main application into smaller libraries?

The DemoApp project is very loosely coupled so it is possible to split the application into smaller library projects along these lines: * services and server delegates * model, events, commands and responders * views


3. Why am I not using the singleton pattern?

Singletons create problems (e.g. it is hard to subclass them) and if it is possible to avoid them it is better to do so.


4. How does dependency injection work in this project?

The main application class (i.e. Application.mxml) is responsible for instantiating the ApplicationManager class. All other classes, including other managers and the model and service locater are instantiated and managed by the Application Manager class which acts as a façade.


5. Why do I use Cairngorm as an underlying framework?

Because Cairngorm is considered a standard in Flex development. I could easily replace the Caingorm classes with my own custom classes but I chose to keep Cairngorm to stick to the standard. One might say that I extended Cairngorm in a similar way that Universal Mind created their Cairngorm-based framework.


6. Why do I split the visual components into the user interface class and the controller class?

There are a few reasons:

  • to make unit testing possible
  • when components get big and complicated the mxml format becomes clumsy and hard to maintain.
  • it gives you a clear separation between view and control so you can easily replace the mxml class and keep the logic in the controller class unchanged.