Home → Solutions →

Command config management

• Edit

zubak.balazs

27 Feb, 2015 02:24 PM

Hi all!

First of all I want to thank you guys that great work you did already with RL!

We use RL2 for about a year, and built a medium level application (about 2000 classes).
Right now I see that our biggest problems are the controllers, and I would like to ask some advice.
In the system the controllers make most of the changes on the application (that mostly triggered by user interaction).

My problem is that there are tons of events that run in the system (many times the same command for different events). And these events only setted in the CommandConfig class, where we connect the events with the commands. But it a single list, and it's almost impossible to understand what is the exact connection between views, models, what are the workflows, etc.

So do you have any recommendation, how to put this CommandConfig in a structure to make it easier to understand the connection between the events and commands?
I would like to reach that simple structure when i look on it everything should be clear like heaven.

Thank you in advance!

1. Support Staff 1 Posted by Ondina D.F. on 27 Feb, 2015 05:08 PM

   

   Hi!

   Thanks for the kind words.

   In my experience, a modular approach can solve this kind of problem.
   By modular approach I mean:

   1. several contexts, aka Modules with their own context
      
   2. one context, with several packages organized in a modular fashion

   An example of a package structure, that I like to use in my projects:

   • shared (or commons)
   • shell
   • modules

   First, I'd look at the functional areas of the application, you know, like login, user admin, image gallery, search, etc. Then I'd create a package for each category, structured like shown bellow. I'll use names like functionalAreaOne, functionalAreaTwo..., just for the sake of an example.
   So, instead of having a single mvcs structure for the entire application, where all the Mediators are under the views.mediators folder, all the Commands under controllers.commands, etc, you'll have as many folders as your defined functional areas / modules, where each 'module' contains its own mvcs.

   --modules

   ------functionalAreaOne

   ------------configs

   ------------------FunctionalAreaOneContex.as //in case this is a Module

   ------------------FunctionalAreaOneConfig.as //in case this is just a subpackage in a one Context app

   ------------------MediatorsConfig.as

   ------------------ServicesConfig.as

   ------------------ModelsConfig.as

   ------------------CommandsConfig.as

   ------------controllers

   ------------------commands

   ------------------events

   ------------services

   ------------models

   ------------views

   ------------------components

   ------------------mediators

   The shared or common package is meant for classes that are shared by many other classes in your app. You can either create sub-packages with meaningful names that are structured like
   any other module, or you just have an mvcs structure for all the shared classes. It depends on your project needs how you handle the common package, but it might help if you think of it as if it was a library that you'd want to use in other projects too.

   The shell package would be also mvcs structured, and it would contain the files for creating the Robotlegs Context and the main config files.

   In your shell's context cofiguration file where you usually have something like this:

   _contextView = new ContextView(contextView);
   context = new Context();
   context.install(MVCBundle);
               
   context.configure(ModelsConfig, ServicesConfig, CommandsConfig, MediatorsConfig);
   context.configure(_contextView);
   

   you can call the 'modular' configs like this:

   context.configure(FunctionalAreaOneConfig, FunctionalAreaTwoConfig, FunctionalAreaThreeConfig, FunctionalAreaFourConfig);
   

   N.B. I'm talking about an application with a single context! In case of an application with several contexts this kind of configuration does not work. Each module would have its own context, that would be created when the module is loaded and would call its own context.configure().

   So, back to the single context. Inside of each functional area, under the config package there would be a config file, like the FunctionalAreaOneConfig, with an IContext injected, that will configure the classes that belong to that 'module'.

   public class FunctionalAreaOneConfig implements IConfig
   {
       [Inject]
       public var context:IContext
   
       public function configure():void
       {
           context.configure(ModelsConfig, CommandsConfig, ServicesConfig ,MediatorsConfig);
       }
   }
   

   Alternatively, you can implement another interface, say IConfigure, so you can do something like this:

   public class FunctionalAreaOneConfig implements IConfigure
   {
       [Inject]
       public function configure(context:IContext):void
       {
           context.configure(ModelsConfig, CommandsConfig, MediatorsConfig);
       }
   }
   

   For example, ModelsConfig will contain the mappings for the models used by functionalAreaOne:

   public class ModelsConfig implements IConfig
   {
       [Inject]
       public var injector:IInjector;
           
       public function configure():void
       {
           injector.map(ISomeModel).toSingleton(SomeModel);
           ...other models
       }
   }
   

   Looking at the shell's config will give you the overall structure of your 'modules'. From a module's config you can understand what's going on in this functional area....

   Does this help?

   Ondina

   • Edit

2. 2 Posted by zubak.balazs on 25 Mar, 2015 05:34 PM

   

   HI!

   First of all thank you very much for your exhaustive answer!
   Sorry for late reply, I was very busy these days.

   We try to separate bigger contexts, but we try to avoid created extra small individual contexts because the communication is not as easy between.

   You also gave some great idea: Put the configurations into packages, so this way i have many smaller configuration files.
   And in the configs we just refer to these packages. Like this:
   this.useMapping( AssetPackageConfig );
   (we implemented in a base config class the useMapping)

   And one more think helped a lot: We started to use macrobot. This way we can collect one command flow in a macro, so this way we only have to add one line to the command config.

   So real point was in three things:
   1. macros
   2. config packages
   3. separate contexts for modules

   Thank you again!

   • Edit

3. zubak.balazs closed this discussion on 25 Mar, 2015 05:36 PM.