Help with splitting Big app into core and extensions
Hello,
I have one big app written in robotlegs. That app also uses one big library written in robotlegs. V2.
My goal now is to take out the core functionality of the app, and the library and then make it usable in web and mobile versions. Since now I was doing two branches, one for web and one for mobile, but it doesn't work that good.
Do you have any suggestions how to make that refactor?
My idea is to use interfaces for models, services and views and to make separate config for mobile where you map values against them.
Is there a similar approach for views and what about different commands end extending their functionality?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | 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
Support Staff 1 Posted by Ondina D.F. on 19 Jun, 2013 10:03 AM
Hi Matej,
Yes, interfaces would solve the problem nicely. The mappings and injections would be the same in different projects.
In fact, everything (Mediators, Models, Services, Commands), including some config files, could be the same.
Only the Views would be different.
First approach: everything is portable. Even Views can be re-used in other projects.
So, each project would load a different library, containing the views specific for that platform, and another library with the common classes(Services, Models…).
If you mapped a view like this:
and you injected it like this in its mediator:
your app would load SomeMobileView in your mobile project, and SomeWebView in your web project.
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(?).
The projects would look very ‘slim’, because they’d only have the root display object that instantiates the context.
Second approach:
Each project contains the platform specific views, and loads the shared rl classes as a library.
The “main” config class for each project could look like this:
WebProject
MobileProject
Within your root display object:
ModelsConfig, ServicesConfig, ControllersConfig, MediatorsConfig, they all implement IConfig. They’d be part of the shared library.
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.
If it’s confusing, let me know, and I’ll try to explain it better:)
Why not? Don’t you mean 2 projects, one for mobile and one for web?
Ondina
2 Posted by matej on 19 Jun, 2013 10:42 AM
I was refering to git branches. CherryPicking alot of commits means trouble :)
You gave me good idea, thanks.
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.
If I run into any problems, I will post here.
Thanks again
Support Staff 3 Posted by Ondina D.F. on 19 Jun, 2013 10:48 AM
You’re welcome, and yes, please re-open this discussion if you run into problems.
Make sure you don't miss our party, next door:)
http://knowledge.robotlegs.org/discussions/problems/2516-let-the-ro...
Ondina D.F. closed this discussion on 19 Jun, 2013 10:48 AM.
creynders re-opened this discussion on 19 Jun, 2013 11:43 AM
Support Staff 4 Posted by creynders on 19 Jun, 2013 11:43 AM
Just wanted to chip in to say that RL2 has covariant mediation, meaning you
can use interfaces for your views as well:
@@@
mediatorMap.map(ISomeView).toMediator(SomeMediator);
@@@
It's definitely a good idea to make use of it.
5 Posted by Vj3k0 on 20 Jun, 2013 04:17 PM
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.
Of course, as Ondina stated, extract commons to separate lib.
Regards,
Vjeko
Support Staff 6 Posted by Ondina D.F. on 21 Jun, 2013 10:16 AM
I guess, this is resolved. :)
Ondina D.F. closed this discussion on 21 Jun, 2013 10:16 AM.