tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/790-modular-application-design-problemRobotlegs: Discussion 2018-10-18T16:35:45Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-02T11:02:04Z2013-02-02T11:02:04ZModular Application Design Problem<div><p>Duplication is a definite no-no.<br>
What is the problem exactly? Racing conditions? E.g. the main
application needs something from the module, while it's not yet
configured?<br>
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?</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-02T15:23:28Z2013-02-02T15:23:28ZModular Application Design Problem<div><p>Thanks for your reply creynders.</p>
<p>I'll try to explain without confusing you.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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?</p>
<p>Thanks for your help,</p></div>mbarjawitag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-03T03:04:13Z2013-02-03T03:04:13ZModular Application Design Problem<div><p>Hi mbarjawi,</p>
<p>I think I kind of understand your question.<br>
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.</p>
<p>If you just have one "project", your folder structure might look
a bit like this:</p>
<ul>
<li>com
<ul>
<li>domain
<ul>
<li>application
<ul>
<li>shell
<ul>
<li>config</li>
<li>model</li>
<li>view</li>
<li>controller</li>
</ul>
</li>
<li>common
<ul>
<li>model</li>
<li>view</li>
<li>controller</li>
</ul>
</li>
<li>module
<ul>
<li>config</li>
<li>model</li>
<li>view</li>
<li>controller</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>Your shell will have it's own config file, and your module will
have it's own config.</p>
<p>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.<br>
Just put all the commonly used commands, views, models, services,
utils, etc. in this 'common' project.</p>
<p>I hope this is somewhat in the direction you were looking
for?<br>
Hans</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-04T08:16:54Z2013-02-04T08:16:54ZModular Application Design Problem<div><p>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.<br>
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.<br>
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.<br>
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.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-07T06:51:27Z2013-02-07T06:51:27ZModular Application Design Problem<div><p>Thank you @dotdotcommadot and @crynders so much for your
help.</p>
<p>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?</p>
<p>If my understanding is correct, I guess then we cannot have Flex
Modules without having<br>
RL Modules... but we CAN have RL modules without having Flex
Modules.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>So any more suggestion and comments about my solution are
greatly appreciated.<br>
Thanks a lot for your help,</p></div>mbarjawitag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-07T11:03:12Z2013-02-07T11:05:46ZModular Application Design Problem<div><p>Of course I'm not sure, but I think you are making things a bit
more difficult than they should be.<br>
First thing to remember is:<br>
A big reason for using modules, is to split up the size of your
application.</p>
<p>(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.<br>
Your initial load (the shell) will be only 250kb, and once you've
selected your module, you will load the other 250kb.<br>
If you exit the module, you can throw away the 250kb of the
module.</p>
<p>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.<br>
So now you have 750 kb.</p>
<p>Just to point out: if you're using modules, make sure you split
up everything clearly!<br>
If you don't use modules well, you will be worse off then just
making one application.</p>
<p>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.<br>
You'll be embedding all of your module's mediators, views,
commands, etc in your shell app!</p>
<p>I'd say, to start off with: make one context for your shell, and
one for your module.<br>
And keep everything separated, unless you need otherwise (then go
for the 'common' approach above).</p>
<p>I once made an example project which might be interesting for
you,<br>
but I'm not sure if it still runs well because I used it to debug
stuff on.<br>
But maybe the overall setup might help you further:<br>
<a href=
"https://github.com/dotdotcommadot/ModularRL">https://github.com/dotdotcommadot/ModularRL</a></p>
<p>Good luck!<br>
Hans</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-11T14:43:22Z2013-02-11T14:43:22ZModular Application Design Problem<div><p>Hey Barjawi,</p>
<p>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:)</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-14T21:22:56Z2013-02-14T21:22:56ZModular Application Design Problem<div><p>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.</p>
<p>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?</p>
<p>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?</p>
<p>Thanks,</p></div>mbarjawitag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-15T12:49:04Z2013-02-15T12:49:40ZModular Application Design Problem<div><p>This <a href=
"http://help.adobe.com/en_US/flashbuilder/using/WSe4e4b720da9dedb5-1a92eab212e75b9d8b2-7ffe.html">
link</a> will explain all :)</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/244827102013-02-15T21:14:07Z2013-02-15T21:14:07ZModular Application Design Problem<div><p>That link explains it very well. Thanks a lot for all the
help.</p>
<p>For now, I'll spend time implementing the new structure. I don't
think I have any other questions in this regard.</p>
<p>Closing thread :)</p></div>mbarjawi