Flex Modular Applications using Robotlegs

Saurabh Narulablog.saurabhnarula.com

Topics

• Robotlegs and Modular utility• Best Practices, Rules & Recommendations

Robotlegs and Modular Utility

Project Organization

• Folder structure – functionality based and not tier/layer based

• Assets folder – all assets• Test folder – all tests• Main contains the source code.

Parts/Actors

• Context – for bootstrapping• Mediator – communication between your view

with the outside objects in your application• Models – store data, represents current state• Services – Applications gateway to the outside

world.• Command – some action you need to perform.

Events and Inject tag

• Events and Inject tag are the two main aspects that help us address dependency injection.

• Inject tag is provided by Robotlegs application framework.

• Events are the Flex framework events.

Framework events

• Use native flash to communicate between the actors – mediators, services, models and commands.

• Use custom events with payloads.• Can be sent through all Actors.• Mediators are the only ones receiving

framework events.• Commands can be triggered in response to

framework events.

Framework events

• An event can be both received by a Mediator as well as trigger a command.

• Model and service classes should not listen for or respond to events.

• Doing so would tightly couple them to application specific logic and reduce the potential for portability and reuse.

Modules

• All view components in our application are modules.

• We use Robotlegs modular utility which helps us provide specific functionality to work with modules.

Modular Utility

• Extend ModuleContext for creating Context• Extend ModuleMediator for creating Module• View should be type module• Model should extend ModuleActor

Views and Mediators

• Mediator mediates interactions with View.• View should strictly contain mxml components

only, no AS code.• Application specific logic should be written in

mediators, to avoid coupling view components to specific applications.

• Mediator listens to events, sends events in response to events received from view components.

Views and Mediators

• Write your initialization code in onRegister() function.

• addModuleListener() listens to events dispatched from other modules.

• addViewListener() listens to events dispatched from View.

• Models should never be injected directly in view/mediators, defeats the purpose of using MVC.

Views and Mediators

• To dispatch events to other modules, use dispatchToModules()

Context

• Bootstrap your module• Extend ModuleContext (and not Context, not

the plain robotlegs Context class)• Declare all injector mappings in startup()

method.• Use injector.mapSingleton([model]) to create

singleton model.• Use injector.mapSingletonOf([Interface],

[service]) to create singleton service.

Context

• Use moduleCommandMap.mapEvent () to map a command against an event.

• Use moduleCommandMap instead of using commandMap(of robotlegs).

• Mediator.mapView() is to map the the mediator with its view

• Call super.start() in the end only, afte doing everything.

Context

• Dispose() should be explicitly called when the module is being unloaded.

• For examplevar module3:IModule3 = mainSectionModuleLoader.child as IModule3;module3.dispose();

Model

• Generally dispatch an event notifying that the model is updated/changed.

• Extend ModuleActor class• Highly portable/loosely coupled entity

Service

• Can inject models here• Sets the model• Services generally do not dispatch events to

other modules, they only update model. Model is the one responsible for notifying any updates on the data – this is a common mistake, avoid this.

• They should be highly portable.

Command

• Short lived stateless objects.• instantiated, executed and then immediately

disposed of.• Commands are only executed in response to

framework events and should never be instantiated or executed by other framework actors.

Command

• At the heart of decoupled application.• Command is never instantiated or executed from

a Mediator, Model or Service.• Commands may:– Map Mediators, Models, Services, or other

Commands within their Context– Dispatch Events to be received by Mediators or trigger

other Commands– Be injected with Models, Services, and Mediators to

perform work on directly

Interaction within modules

• Use Events to interact within modules.• Make sure the event is dispatched from the

source module and the module listener is present in the mediator where you intent to listen for this module.

Request & Response Model

• Make sure you are not making duplicated data calls when the module gets loaded or unloaded, do not call service again to populate model again if the model is already present.

• Use Request and Response event model to request for the model for a particular module.

• http://knowledge.robotlegs.org/discussions/questions/454-requesting-data-from-mediator-instead-of-injecting-model

Request & Response Model

• Request for model when the module loads.• Request is mapped with a command.• Dispatch response event from command if the

data is already present.• If data needs to fetched again or not available,

changed event is dispatched from data model.• Listen to both response and changed event in

your view’s mediator.

Best practices, Rules and Recommendations

Load/Unload Modules

• http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf64277-7ffd.html

• http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7f22.html

Rules, Best Practices

If there is anything to be shared across modules, makes sure that it is available before a module is loaded.

Request Response Module

Whenever a module loads up, first load local filters etc. and then make a request for data model by dispatching Data Model Request event and executing respective/mapped command.

Dependency & Integration issues across Modules

All the issues of integration and dependency within modules would be resolved if we follow the two approaches mentioned in the slides before.

Sample Module Layout

Module 2: Filter selections module (containing drop down etc. to drive the rest of the application)

Module 3: Main Section Module 1 (Load/Unload child modules)

Module 1: Main Module (Never Unloaded)

Module 4: Sub/Child Module (can have more such child modules - Module 5, Module 6 etc., loaded/unloaded by Main Section Module 1)

Module loading Flow

Step 1: Main Module loads first by default after logging in to the application.Step 2: As part of loading Main module, load data (model) required for Module 2.Step 3: Load any other data (model) that’s required to be shared across multiple modules at the same level.[Following our rule here, preload anything here that might be shared across modules]

Module loading Flow ..

Step 4: Load Module 2Step 5: Module 2 needs data for populating filters, It will dispatch Request event to request for its data, which in turns executes a command and sends back a response event with data as a payload in the response event.Step 6: Module 2 dispatches a module ready event notifying its parent module – Main Module 1 that its ready and main module can now load Module 3 on its right.

Module loading Flow ..

Module2DataModel can look like thisModule2DataModel{

filters1:ArrayCollection;filters2:ArrayCollection;

//store the value which represents the current data i.e. we are storing the request’s parameter’s values which were used to fetch this data.value1:String;

//store default selections, defaulting to 0selectedFilter1Index:Int = 0;selectedFilter2Index:Int = 0;

}

Module loading Flow ..

Step 7: Main module, Module 1 then loads module 3 after being notified about the module 2’s ready event.Step 8: Under module 3, load if there is anything specific to module 3 and needs to be shared across its child modules i.e module 4, module 5 and so on..

Module loading Flow ..

Step 9: Load Module 4.Step 10: Before requesting for its data, load/request local filters if any – reuse/request filter values which are already loaded as part of the main module 1 loading process.Step 11: Request for data model by dispatching Module 4’s Data Model Request Event, which in turn executes the mapped command. The request event can also carries any selection values (request parameters) to be sent to the service, alternatively this can be avoided since the current selections can be retrieved from the respective filter’s data models.

Module loading Flow ..

Module 4’s filter data model can look like thisModule4FilterDataModel{

//each filter in the ArrayCollection is of type FilterVOmodule4Filter: ArrayCollection;

//store selection, default it to 0selectedModule4Filter:Int = 0;

}

Module loading Flow ..

Module 4’s Data Model can look like thisModule4DataModel{

//each object in ArrayCollection is of type Module4VOdata: ArrayCollection;

//store data that is used to fetch this data i.e. filter values or request //parameter values

requestParameter1: String;requestParameter2: String;requestParameter3: String;

}

Avoid making duplicated data calls

When you navigate away from the module, it gets unloaded from the memory, but its data is still in the memory. Since we already store the filter values which retrieved this data for us, when we again try loading this module, and we request for its data model, at that time we can check the filter values /request parameters which are already stored as part of the data model vs. the new filter values/request parameters for which we require the data, if both are same, return the existing data, if not make the new service call and respond with changed event from the data model.

Avoid making duplicated data calls• Example –Module4DataRequestCommand{

[Inject]event:Module4DataRequest;[Inject]model:Module4Model;[Inject]service:Module4Service;

function execute():void{

if (model. requestParameter1 != event. value1 || model. requestParameter1 != event.value2 || model.requestParameter1 != event.value3)

{//service.fetchModule4Data(event.value1, event.value2, event.value3)}else{dispatch new Module4DataEvent .RESPONSE(model);}

}

}

Best practices & Common Issues

• Best practices - https://github.com/robotlegs/robotlegs-framework/wiki/Best-Practices

• Common Issues - https://github.com/robotlegs/robotlegs-framework/wiki/Common-Problems

Credit and References• Robotlegs home page

– http://www.robotlegs.org/• Robotlegs diagram

– http://www.robotlegs.org/diagram/• Robotlegs modular utility - helper classes for building modular apps with Robotlegs.

– https://github.com/joelhooks/robotlegs-utilities-Modular• Sample Modular applications

– http://labs.riamore.com/content/robotlegs/examples/dynmodules– http://joelhooks.com/2010/05/02/modular-robotlegs/

• Finite State Machine for Robotlegs– https://github.com/joelhooks/robotlegs-utilities-StateMachine

• Injecting data model– http://knowledge.robotlegs.org/discussions/questions/467-how-to-take-data-from-model– http://

knowledge.robotlegs.org/discussions/questions/454-requesting-data-from-mediator-instead-of-injecting-model

– http://knowledge.robotlegs.org/discussions/questions/309-inject-model-into-the-mediator