tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/804-adding-a-view-inside-another-view-via-a-commandRobotlegs: Discussion 2018-10-18T16:35:36Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/132335872012-01-28T09:11:01Z2012-01-28T09:47:10ZAdding a View inside another View via a Command<div><p>I would recommend against manipulating the display list by a
command:</p>
<ul>
<li>
<p>it gives the command too much knowledge about the display list
hierarchy</p>
</li>
<li>
<p>it's view logic</p>
</li>
</ul>
<p>And IMO the mapping of views to mediators should happen in one
or more view bootstrapping commands, because it centralizes the
view mappings.</p>
<p>In fact in all my applications the adding and removing of
display objects is entirely the responsibility of the view tier
itself. Display objects expose public methods that can be called by
other display objects (either directly or through events) to add or
remove other display objects, or if a display object is mediated
the methods can be called by the corresponding mediator as well (in
response to a system-wide event).<br>
This setup is extremely flexible, in my experience display objects
easily change place in display list hierarchy and if the system is
aware of their hierarchical place you'll need to make changes
in-system every time.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/132335872012-01-28T18:08:03Z2012-01-28T18:08:03ZAdding a View inside another View via a Command<div><p>Ok that makes sense.</p>
<p>I can certainly restructure things around so that my new views
are created within another view rather than in a command. It would
be easy then to add this view inside others.</p>
<p>I have a startup command that runs once when my app is started,
is this a good place then to map <em>all</em> my views to
meditators?</p></div>Ryan Yacyshyntag:robotlegs.tenderapp.com,2009-10-18:Comment/132335872012-01-29T18:59:43Z2012-01-29T18:59:43ZAdding a View inside another View via a Command<div><p>Well, yes and no. :)<br>
With very small applications you can get away with putting all
bootstrapping code in one command, but it quickly becomes huge and
gives problems when the bootstrapping requires the addition of some
kind of async process.<br>
The common way is to map 3 separate commands to the STARTUP event
:<br>
BootstrapModels<br>
BootstrapControllers<br>
BootstrapViews</p>
<p>Personally I add 2 more:<br>
BootstrapCore<br>
BootstrapServices</p>
<p>And if it's a really big application I have all 5 commands for
each functional "unit".</p>
<p>Here's an example of a more complex bootstrapping process:
<a href=
"https://github.com/creynders/robotlegs-demo-bootstrap">https://github.com/creynders/robotlegs-demo-bootstrap</a></p></div>creynders