Main

Flex Shell 0.6.1

What is Flex-Shell?

Demo : http://amostudio.com:8080/fs-demo/flex/Main.html#

Flex-Shell is a Shell(Wrapper) style Framework Designed for Flex 2/3 development.

Flex-Shell enforces simplicity and unobstructiveness of development code
while same time provides powerful engine and features that are up to developer how they can be utilized...

Flex-Shell is based on Colibri Configuration Engine which I have wrote and implemented in J2EE
open source project coffeJ (which is still behind in development at this moment) but idea is to make these two frameworks
intercompartible (at some point, would be nice at least :)

Flex-Shell heavily uses Flex's native Module component and provides API for developer to easily load Modules into application.
on top of that,Flex-Shell provides plugin api to easily develop unlimited number of plugins for application and load at runtime.
Flex-Shell Also provides powerful Policy Based Module and Plugin Loading API which can be configured with numerous parameters

Flex-Shell's core consist of three components(no actually its four)
or to be more clear its three and a half, ... anyways let's move on .. :) . major components of Flex-shell are :

• Configuration Engine(Colibri)
• Core Engine
• System manager
• Security Manager
• Application Mananger

NOTE: Each Manager is maintained as a Single Instance(Singleton pattern), and they are created automatically by framework,
you can't instantiate them directly,(well if AS3 would support private cnstructors, this statement would be 100% true);

in order To obtain the instance of particular manager do :

Configuration Engine

Configuration Engine is a key feature of Flex-shell. it takes Flex development on next level,
providing very flexible xml configuration based approach .

Full Configuration xml fshell-config.xml

Hierarchy of fshell-config.xml resembles the hierarchy of flex-shell framework itself.
inside flex-shell Framework there is CoreEngine, which has have three Managers;
each Manager(including CoreEngine itself) has Corresponding Node inside fshell-config.xml:

• CoreEngine

• SysManager(not Flex's SystemManager)

• SecurityManager

• ApplicationManager

As you see,each manager's xml configuration nodes are similar to each other,
so lets examine the general similarities.:

• property - each manager's (and not only managers but also plugin's) node can have unlimited number of property nodes :

property nodes are automatically parsed and placed inside properties object of a manager they belong to.
property values can be obtained during runtime by calling :

• module- ApplicationManager can have unlimited number of modules, they are regular flex modules,
  and they get loaded based on their loading Policy automatically by framework (see belove regarding module loading policy)

• plugin - SysManager, SecurityManager, ApplicationManager can have unlimited number of plugin nodes.

What is Plugin ?

Plugins are regular modules with some twist :)
.plugins get loaded same way as modules,following same policy rules,
As soon as plugin gets loaded, it is automatically created and plugged into initialization chain,
at that time plugin's init method is called, giving plugin chance to initialize itself.
all plugins must implement IPlugin Interface.
(See: SecurityManager ,--> authentication Plugin source ) ---

• service - each manager can also have service node.
  

What is Service Node ?

Service node is used to dynamically append additional configuration xml to manager, using service call,
for example: SecurityManager needs to call backend Service to obtain list of allowed roles in the application :

service node attributes are :

• • forName - specifies name of the root xml that service call will return,
    so for this example servcice must return xml that has root node roleRegistry
  • type - specifies type of service call, currently only httpService is supported.
  • url - specifies url of the service that will return xml.

this service call returns xml in following format :

Module Loading & Policy Configuration

Module Loading, based on Policy and Priority values provides configuration that tells engine
how and when(at what point of runtine-lifecylce of the application) to load desired module(s) into application,
it is configurable through flex-shell.xml file and provides great flexibility to developer.
For example : if developer wishes to have N number of module(s) loaded into application all he/she has to do is compile regular flex module(s) and in cofiguration put something like this :

• • loadPolicy (attribute) - Supported values :
    • preload - preloads(and creates) module before application container is loaded
    • onDemand - Registers Module and waits API Call from User's application code such as :

• • • roleBased (*Requires Security Manager to be turned on and attribute role to be specified) will load module only if user has same role as specified for attribute role. example

role name can be anything developer wishes to, as long as this role is declared under SecurityManager Configuration Node in flex-shell.xml file(about it later on ) .

• • • firstAuth preload only when user logs into the system first time.

All this information is enough for application to take this module and load it for user at runtime. all user has to do is listen for module Event(regular Flex ModuleEvent.READY) (this might change the future).

Security Manager - is Second Biggest Part of the Flex-Shell Framework, (which can be easily turned off and ignored, if developer does not wish to use it ) providing flexible, configurable security Management, (in future idea is to make it service pluggable so user can create a custom Service ABC and plugit into security Manager as custom authentication mechanism) .

System Manager - is class that provides all system level operations such as advance components for debugging, memory monitoring stack trace display API, also (still in development) to provide solution to run unnecessary object reference(including circular references) cleanup to helpout Garbage Collector, this is done by having classes(components) implement ISystemManagable interface if they have code that can be cleaned up when system Manager runs cleanup method.

How to Use Flex-shell

Flex-shell starts by including mxml

in your main application,

why including and not extending Application ?

by including developer gets almost non obtrusive development environment,
where he/she can still code outside colibri:Shell ,
everything that goes inside of colibri:Shell becomes part of flex-shell framework,

So,what kind of children can colibri:Shell have?

good question,
colibri:Shell can have Direct children that implement api.app.IView interface,

to make it more clear, colibri:shell is a extended, managed ViewStack Object,
it maintains three View Containers, one for each manager :

• SecurityManager View Container
• SystemManager View Container
• ApplicationManager View Container

two of the manager's already have default view, but ApplicationManager does not,
and thats what you meed to provide

that means, at minimum flex-shell should have following :

• local:Index - is your mxml file,it does not have to be Named Index,
  it can be anything you want,but it should implement api.app.IApplicationView Interface,
  so that flex-shell can associate it with ApplicationManager.

TODO ...

Flex Shell Lifecycle

in Two minutes or less

• Flex-shell.xml Configuration file is parsed(or to be more AS3-ish : Configuration file is e4x-ed)
• CoreEngine is Configured and all CoreEngine's only, registered plugins are loaded and executed(this is needed to load ConfigurationFactory Module(plugin) which is responsible to configure all other components(after that ConfigurationFactory module is unloaded and discarded, freeing up memory )
• Core Components are Configured which are: CoreEngine,SystemManager, SecurityManager(if Turned on) and ApplicationManager)
• all Plugins and/or Modules are configured and prepared to be Loaded.
  • Plugins/Modules are sorted and grouped, based on Loading Policy and Loading Priority attribute values, they have assigned .(NOTE system Modules are always carry preload policy and they have highest loading priority than regular application(developer's modules/plugins).
• CilibriLoader is Configured and all System Modules and application modules are loaded.

• • NOTE There is two possible ways to Load Modules :
    • asynchronously --- ColibriLoaded will iterate through all configured modules and call load on each one, not waiting for previous module to finish loading (fastest way )
    • synchronously --- ColibriLoader will Load one Module at a time and will wait until first Module is completely loaded before calling load on another Module.

• • NOTE (IN DESIGN) ColibiLoader currently is one Class it will be refactored and modularize to support SWLLoading as well so there will be :

• AsyncModuleLoader
• SyncModuleLoader
• SWFLoader

When all 'preload" policy Modules are loaded ColibriCoreEvent is dispatched. Core engine receives event notification and transitions into next phase which is to run all remaining initialization code and transition into SECURITY_ACTIVATED state, (loading SecurityManager with assocciated View ). For each transition CoreEngine dispatches FlexShellEvent with currentState attribute. if SecurityManager is turned off CoreEngine immediately transitions into APPLICATION_ACTIVATE State and then Developers Code lifeCycle begins. CoreEngine's internal States are :

To be Continued ...