Modular Application Design Problem

mbarjawi's Avatar


01 Feb, 2013 09:14 PM


I am facing a design problem with a modular application that uses Robotlegs 2. The main application and module, each have their own bootstrap configuration routines, which takes care of mapping the signals, commands, behaviors, models, services, and dialogs. Now, I want to use some of the module's views and actions in the main application. I can't figure out how to do this, in order to maintain a good practice. The options I have came up with so far, are:

  • Moving the module configuration that are needed in the main application, to the main application itself. This will tear apart the module's configuration into two parts, which doesn't seem right.
  • Moving all the module configuration to the main application. But this would mean the modules will only have skins and views!
  • Duplicating the needed items from the module into the main application. This would be wasteful and hard to maintain for future changes.

I am really confused, as I also need some of the views from the module in other modules as well, and I have no clear way of doing this. Any help is highly appreciated!


  1. Support Staff 1 Posted by creynders on 02 Feb, 2013 11:02 AM

    creynders's Avatar

    Duplication is a definite no-no.
    What is the problem exactly? Racing conditions? E.g. the main application needs something from the module, while it's not yet configured?
    Or you don't know how to address the elements from the module in your main application w/o compiling them into the main app?

  2. 2 Posted by mbarjawi on 02 Feb, 2013 03:23 PM

    mbarjawi's Avatar

    Thanks for your reply creynders.

    I'll try to explain without confusing you.

    So basically I have an educational application that I started to chop into modules because it is huge and it needs renovations in many areas. I started with the area where the user creates a study plan for the student. I finished this module and now the user can create/edit/delete study material and courses, as well as being able to assign/remove study material to/from the student's study plan. I called this module the StudyPlanModule.

    Now in other areas of the application (that should be renovated in the future to become separate modules as well), the user needs to see the student study plan and interact with it. The study plan itself is in the StudyPlanModule module and all of its interactions (signals/commands/behaviors...etc/) are in the module as well. I can easily access the StudyPlanView from the main application, however nothing works in that view because all of the signals/commands/behaviors are configured inside the module's injector.

    So I am not sure if even accessing the module views from the main application is a fine or not. If it is, then how to accommodate for all the configuration that is injected into a different injector in the module.

    I was thinking of one solution, and again not sure if it is a good practice or not. I was thinking about calling the module's configuration commands from the main application (so that they get configured using the main application's injector).

    I think one of the questions that confuses me is the degree of separation between the module and the main application. Should I be programming the module with the idea in mind that this module could be loaded from any application in the future, so I should make it self dependent... or is it ok to have some coupling/dependability between the current main application and the module?

    Thanks for your help,

  3. 3 Posted by dotdotcommadot on 03 Feb, 2013 03:04 AM

    dotdotcommadot's Avatar

    Hi mbarjawi,

    I think I kind of understand your question.
    To me it seems like you have to make a separation to what is ony relevant in the module, what is only relevant in the shell (or 'Main application'), and what parts they have in common.

    If you just have one "project", your folder structure might look a bit like this:

    • com
      • domain
        • application
          • shell
            • config
            • model
            • view
            • controller
          • common
            • model
            • view
            • controller
          • module
            • config
            • model
            • view
            • controller

    Your shell will have it's own config file, and your module will have it's own config.

    If you created two separate projects for the shell and the module, just make a third project: 'common', and use this as a library project in both the other projects.
    Just put all the commonly used commands, views, models, services, utils, etc. in this 'common' project.

    I hope this is somewhat in the direction you were looking for?

  4. Support Staff 4 Posted by creynders on 04 Feb, 2013 08:16 AM

    creynders's Avatar

    What dotdotcommadot said. And also, you have to make a distinction between flex modules and RL modules. Flex modules are RSL's. RL modules are encapsulated parts of (an) application(s) that operate separately from the other parts.
    This means that if you got a service class, for instance, that you want to use in various modules independently [!] then you can put the implementation into a RSL and leave the mapping/configuration/usage of that class into the RL modules that use it.
    However, if you have a service that you encapsulate into a RL module and you want other modules to be able to "control" that service, you need to setup intermodular communication through events. That's how modules and the main application communicate with each other: events.
    So, leave the config into your module. Map events to the appropriate commands or let mediators listen to those events. Then have your main application dispatch the events when needed.

  5. 5 Posted by mbarjawi on 07 Feb, 2013 06:51 AM

    mbarjawi's Avatar

    Thank you @dotdotcommadot and @crynders so much for your help.

    Is it then possible to create different contexts inside the same application without having to have Flex Modules in the application? Is this what RL Modules are? What are the benefits of such modules?

    If my understanding is correct, I guess then we cannot have Flex Modules without having
    RL Modules... but we CAN have RL modules without having Flex Modules.

    My application is big and complicated. I started re-building it a while ago... after that I met Robotlegs and since then I have been using it for redesigning my application.

    In my current architecture, I have a shell application which has its own configuration commands. I also have a Flex Module that has its own configuration commands as well. The module and shell are both in a single Flex Project. To solve my problem, I just called the Module's configuration commands from the Shell. This way, the Module's configurations are now available through the main application. Right now, I have one module. However, the further I go into this redesigning process, the more modules will come out. I was wondering if I keep mapping everything through the shell application - like I did with the first module - problems would start to happen.

    The "service" example that you give in your post is good but does not cover my case. Actually, I use something similar to the "service" example. I actually have Flex Library projects that include the Services, VOs, Models...etc... but not the commands/signals/behaviors. My case consists of sharing a view component that has behaviors attached to it, those behaviors/mediators dispatch framework signals...etc.

    My solution that I mentioned above ( mapping everything in the main application ) solves this problem. But not sure if it is the right way to go about doing it.

    I was thinking that maybe I shouldn't be sharing a view component. Instead, I should just create a different component in the shell application. However, this new component needs to be able to call some commands from the module.

    I was thinking of moving the mappings from the module to the main application but ONLY for those things that are needed by others. But this will tear the Module apart as some of its configs are in one place an the rest are in another.

    So any more suggestion and comments about my solution are greatly appreciated.
    Thanks a lot for your help,

  6. 6 Posted by dotdotcommadot on 07 Feb, 2013 11:03 AM

    dotdotcommadot's Avatar

    Of course I'm not sure, but I think you are making things a bit more difficult than they should be.
    First thing to remember is:
    A big reason for using modules, is to split up the size of your application.

    (To put it in very retarded terms, but to make the example clear:) Let's say you have a shell of 250kb, and a module of 250kb.
    Your initial load (the shell) will be only 250kb, and once you've selected your module, you will load the other 250kb.
    If you exit the module, you can throw away the 250kb of the module.

    But, if your shell has dependencies towards your module, your shell will be 500kb (shell + module) and for the module you will load again a 250kb module.
    So now you have 750 kb.

    Just to point out: if you're using modules, make sure you split up everything clearly!
    If you don't use modules well, you will be worse off then just making one application.

    If some class (whether it's a context, a command or whatever) in your shell has access to your module's context, you already have too much dependencies I think.
    You'll be embedding all of your module's mediators, views, commands, etc in your shell app!

    I'd say, to start off with: make one context for your shell, and one for your module.
    And keep everything separated, unless you need otherwise (then go for the 'common' approach above).

    I once made an example project which might be interesting for you,
    but I'm not sure if it still runs well because I used it to debug stuff on.
    But maybe the overall setup might help you further:

    Good luck!

  7. Support Staff 7 Posted by Ondina D.F. on 11 Feb, 2013 02:43 PM

    Ondina D.F.'s Avatar

    Hey Barjawi,

    Camille and Hans have answered your questions. I think that you can close the discussion, if you don’t need further assistance with this issue:)


  8. 8 Posted by mbarjawi on 14 Feb, 2013 09:22 PM

    mbarjawi's Avatar

    I have decided to use the "common" structure. So I created a new flex library project and called it Common. In this I am planning on adding a folder for every other module that needs to share some of its items with others.

    My question is, if this library project gets big... doesn't that affect my application in terms of that each of my modules as well as the main application will have to include this big project in order to use only some of its parts?

    Or is it the case that when I compile a module, the only things that will be compiled from the Common library project are the classes actually referenced in the module?


  9. 9 Posted by dotdotcommadot on 15 Feb, 2013 12:49 PM

    dotdotcommadot's Avatar

    This link will explain all :)

  10. 10 Posted by mbarjawi on 15 Feb, 2013 09:14 PM

    mbarjawi's Avatar

    That link explains it very well. Thanks a lot for all the help.

    For now, I'll spend time implementing the new structure. I don't think I have any other questions in this regard.

    Closing thread :)

  11. mbarjawi closed this discussion on 15 Feb, 2013 09:14 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac