tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/3285-help-with-splitting-big-app-into-core-and-extensionsRobotlegs: Discussion 2013-06-21T10:16:24Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/273931422013-06-19T10:03:06Z2013-06-19T10:03:06ZHelp with splitting Big app into core and extensions<div><p>Hi Matej,</p>
<p>Yes, interfaces would solve the problem nicely. The mappings and
injections would be the same in different projects.</p>
<p>In fact, everything (Mediators, Models, Services, Commands),
including some config files, could be the same.<br>
Only the Views would be different.</p>
<p>First approach: everything is portable. Even Views can be
re-used in other projects.<br>
So, each project would load a different library, containing the
views specific for that platform, and another library with the
common classes(Services, Models…).</p>
<p>If you mapped a view like this:</p>
<pre>
<code>mediatorMap.map(ISomeView).toMediator(SomeMediator);</code>
</pre>
<p>and you injected it like this in its mediator:</p>
<pre>
<code>[Inject]
public var view:ISomeView;</code>
</pre>
<p>your app would load SomeMobileView in your mobile project, and
SomeWebView in your web project.</p>
<p>This way, you’ll end up having 2 projects: MobileProject
and WebProject, and 3 libraries: MobileViewsLib, WebViewsLib, and,
er.. I don’t know how to name the library for the rl classes,
SharedRL(?).<br>
The projects would look very ‘slim’, because
they’d only have the root display object that instantiates
the context.</p>
<p>Second approach:<br>
Each project contains the platform specific views, and loads the
shared rl classes as a library.</p>
<p>The “main” config class for each project could look
like this:</p>
<p>WebProject</p>
<pre>
<code>public class AppContext
{
private var context:IContext;
public function AppContext (view:DisplayObjectContainer)
{
context = new Context()
.install(MVCSBundle)
.configure(ModelsConfig, ServicesConfig, ControllersConfig, MediatorsConfig )
.configure(WebConfig)
.configure(new ContextView(view));
}
}</code>
</pre>
<p>MobileProject</p>
<pre>
<code>public class AppContext
{
private var context:IContext;
public function AppContext (view:DisplayObjectContainer)
{
context = new Context()
.install(MVCSBundle)
.configure(ModelsConfig, ServicesConfig, ControllersConfig, MediatorsConfig )
.configure(MobileConfig)
.configure(new ContextView(view));
}
}</code>
</pre>
<pre>
<code>public class MediatorsConfig implements IConfig
{
[Inject]
public var mediatorMap:IMediatorMap;
public function configure():void
{
mediatorMap.map(IsomeView).toMediator(SomeMediator);
}
}</code>
</pre>
<p>Within your root display object:</p>
<pre>
<code>context = AppContext (this);</code>
</pre>
<p>ModelsConfig, ServicesConfig, ControllersConfig,
MediatorsConfig, they all implement IConfig. They’d be part
of the shared library.</p>
<p>If you need specific configurations for each project, you can
define them in a separate config class, say MobileConfig and
WebConfig (implementing IConfig), which are not part of the
library.</p>
<p>If it’s confusing, let me know, and I’ll try to
explain it better:)</p>
<blockquote>
<p>Since now I was doing two branches, one for web and one for
mobile, but it doesn't work that good.</p>
</blockquote>
<p>Why not? Don’t you mean 2 projects, one for mobile and one
for web?</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/273931422013-06-19T10:42:47Z2013-06-19T10:42:47ZHelp with splitting Big app into core and extensions<div><blockquote>
<p>Why not? Don’t you mean 2 projects, one for mobile and one
for web?</p>
</blockquote>
<p>I was refering to git branches. CherryPicking alot of commits
means trouble :)</p>
<p>You gave me good idea, thanks.<br>
I will split the classes that will be used in both web and mobile
into a separate library. And I will make one web and one mobile
library that I will load depending on the project.</p>
<p>If I run into any problems, I will post here.</p>
<p>Thanks again</p></div>matejtag:robotlegs.tenderapp.com,2009-10-18:Comment/273931422013-06-19T10:48:23Z2013-06-19T10:48:23ZHelp with splitting Big app into core and extensions<div><p>You’re welcome, and yes, please re-open this discussion if
you run into problems.</p>
<p>Make sure you don't miss our party, next door:)</p>
<p><a href=
"http://knowledge.robotlegs.org/discussions/problems/2516-let-the-robotlegs-2-party-begin-everyones-invited">
http://knowledge.robotlegs.org/discussions/problems/2516-let-the-ro...</a></p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/273931422013-06-19T11:43:12Z2013-06-19T11:43:12ZHelp with splitting Big app into core and extensions<div><p>Just wanted to chip in to say that RL2 has covariant mediation,
meaning you<br>
can use interfaces for your views as well:</p>
<pre>
<code>mediatorMap.map(ISomeView).toMediator(SomeMediator);</code>
</pre>
<p>It's definitely a good idea to make use of it.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/273931422013-06-20T16:17:54Z2013-06-20T16:17:54ZHelp with splitting Big app into core and extensions<div><p>The point of RL that it is micro framework and that views don't
depend on rest of the framework. You should organize (refactor)
your code so that you can only change mediators and views.</p>
<p>Of course, as Ondina stated, extract commons to separate
lib.</p>
<p>Regards,<br>
Vjeko</p></div>Vj3k0tag:robotlegs.tenderapp.com,2009-10-18:Comment/273931422013-06-21T10:16:22Z2013-06-21T10:16:22ZHelp with splitting Big app into core and extensions<div><p>I guess, this is resolved. :)</p></div>Ondina D.F.