tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/12752-robotlegs-multiview-project-structureRobotlegs: Discussion 2015-03-09T10:31:29Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/362069782015-03-05T18:08:31Z2015-03-05T18:08:31Zrobotlegs multiview project structure <div><p>Hi Ismail,</p>
<p>My FlashBuilder can't import your project for some reason.
Please, just attach a zip file containing your project classes,
without the flashbuilder settings and config files.<br>
I'll take a look at your project tomorrow and let you know about my
findings.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/362069782015-03-05T18:12:22Z2015-03-05T22:31:14Zrobotlegs multiview project structure <div><p>Hi Ondina.</p>
<p>Thank you for your interest.</p>
<p>Here is the zip file:</p></div>ismailtag:robotlegs.tenderapp.com,2009-10-18:Comment/362069782015-03-06T11:04:10Z2015-03-06T11:04:10Zrobotlegs multiview project structure <div><p>Your project's structure looks good. It shows that you already
understand the basics of robotlegs and mvcs. Well done:)</p>
<p>You use interfaces for views, which I think is good. You're not
using any models yet, but when you'll do, try to use interfaces as
well. Same thing for services.</p>
<p>You have a dispose method in your views, where you remove
dependencies and listeners, which is very good in terms of garbage
collection.</p>
<p>You use a VO to transport data between classes, which is also
very good.</p>
<p>You use a config file for each 'module', which I find to be the
best way to organize the configuration of classes in a large
application.</p>
<p>So, all in all, you are on the right path :)</p>
<blockquote>
<p>I create a structure for that but I am not sure I doing it
correctly. It works but when it will grow and get bigger will it
get trouble for me?</p>
</blockquote>
<p>What kind of trouble are you expecting? What exactly makes you
worry?</p>
<p>In my experience, a 'modular' structure, like the one you used,
is best suited for large projects.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/362069782015-03-06T11:30:04Z2015-03-06T11:30:05Zrobotlegs multiview project structure <div><p>I am very happy to all good news from you. Thanks for your
analysis :)</p>
<p>I expect or I confuse about that:</p>
<p>I am trying to code an aministration panel. There will be a lot
of views like "Project Managment", "User Managment" etc.</p>
<p>In my Main class should I define them like that:</p>
<p>context = new Context()<br>
.install(MVCSBundle, SignalCommandMapExtension)
.configure(AppConfig) .configure(WrapperConfig)
.configure(LoginPanelConfig) .configure(ProjectsPanelConfig)
.configure(UsersPanelConfig) .configure(SomeDifferentPanelConfig)
.configure(VeryInterestingPanelConfig)
.configure(WeNeedThatPanelConfig)
.configure(JustForHelloWorldPanelConfig) .configure(new
ContextView(this));</p>
<p>If I will code like that my I suppose my application will use a
lot of system source. Or maybe that is what the solution is. I do
not know. It is made me confused.</p>
<p>I am so grateful for your answer. Thank you very much again.</p></div>ismailtag:robotlegs.tenderapp.com,2009-10-18:Comment/362069782015-03-06T12:13:51Z2015-03-06T12:13:52Zrobotlegs multiview project structure <div><p>And the other confusing point is, where should I do the form
validation or the other logical codes (for each loops, string
trims, array splice etc)? In mediator? I do not think so. In view.
It can not be. In commands?</p>
<p>With these questions answers I will contuniue coding. I guess my
mind will be very clear with your answers.</p>
<p>Thank you again.</p></div>ismailtag:robotlegs.tenderapp.com,2009-10-18:Comment/362069782015-03-06T14:38:19Z2015-03-06T15:18:15Zrobotlegs multiview project structure <div><p>You're welcome, Ismail! I'm glad I could help.</p>
<blockquote>
<p>If I will code like that my I suppose my application will use a
lot of system source.</p>
</blockquote>
<p>The config classes that implement IConfig get garbage collected
after the context has been initialized. You can see that if you use
a profiler, like the FlashBuilder Profiler.</p>
<p>Views and Mediators get garbage collected when the views are
removed from stage.</p>
<p>Commands get garbage collected immediately after execution.</p>
<p>Events aren't kept in memory. With Signals you have to take care
yourself of removing listeners, but it seems that you've already
understood how to do that.</p>
<p>Models injected as interfaces into Commands get garbage
collected.</p>
<p>Depending on your projects requirements you might want to use
swf modules. With the structure you intend to have for your
project, it is really easy to create modules out of the classes
under one package. For example, you could decide to have a login
module, that you load when the app starts and unload when the user
logged in successfully . Each module has its own context, which is
created when the module is added to the stage, and destroyed when
the module is removed from stage. The module with all its classes
gets garbage collected.</p>
<blockquote>
<p>And the other confusing point is, where should I do the form
validation or the other logical codes (for each loops, string
trims, array splice etc)? In mediator? I do not think so. In view.
It can not be. In commands?</p>
</blockquote>
<p>Yeah, that's a good question, but quite difficult to answer. The
Mediator is the wrong place for validation in my opinion, too.</p>
<p>There are many opinions about the right place for form
validation. In part, it depends on the overall design of your app,
on your preferences and on the type of validation.</p>
<p>Some prefer to do that inside the view. Some others do it in a
command.</p>
<p>I prefer to use helper classes for validation of input fields,
like empty fields checking, length of a string, email check,
trimming strings, etc and other operations.<br>
Now, how you use these helper classes, is up to you.<br>
You can inject them into a mediator, which will pass them to the
view.</p>
<p>Or, you can inject them into a command and send the data to be
validated (VO) via an event from the
view->-mediator->command->helper class. You can create
different commands for different kinds of validation, if you want.
For example an EmailValidationCommand that calls a validateEmail()
method on the helper class.</p>
<p>Or you could have the validation logic inside a command.</p>
<p>Another approach could be to have the views extend a base view,
which has a set of validation methods.</p>
<p>As I said, it's hard to say what's best, because it depends on
too many factors. A very simple operation, like just trimming an
input string, isn't worth the effort of dispatching an event with a
vo->mediator->command->helper
class->event->mediator->view.<br>
The input field itself could be a component extending a base
component with this functionality already included (on focus out
->trim string).<br>
On the other hand, if you're doing lots of validations, checking
and manipulation of the input data, I'd consider using a helper
class, either used by the view itself or inside a command.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/362069782015-03-07T16:30:46Z2015-03-07T16:30:47Zrobotlegs multiview project structure <div><p>Thank you again Ondina. This is very helpful and clear. I can
use Robotlegs without any trouble now.</p></div>ismailtag:robotlegs.tenderapp.com,2009-10-18:Comment/362069782015-03-09T10:31:10Z2015-03-09T10:31:10Zrobotlegs multiview project structure <div><p>Once again, you're welcome, Ismail!<br>
Enjoy and have fun with robotlegs :)</p></div>Ondina D.F.