tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/396-two-mediators-and-a-command-to-change-oneRobotlegs: Discussion 2018-10-18T16:35:33Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/105605902011-10-11T23:49:54Z2011-10-11T23:49:54ZTwo Mediators and a command to change one...<div><p>Hi there,</p>
<p>you can't inject mediators into other objects - and a mediator
should be light with no api beyond onRegister / onRemove, so the
normal practice is to only communicate with mediators via
events.</p>
<p>Your command can dispatch an event for the mediator to catch,
or, if you're only dealing with transitions here, you can inject
the same signal into both mediators and wire it up that way.</p>
<p>hth,</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/105605902011-10-12T00:05:01Z2011-10-12T00:05:03ZTwo Mediators and a command to change one...<div><p>Hi Stray,</p>
<p>Thanks for the fast reply AND clearing the first two things
up!<br>
I presume this has been said by you to beginning RobotLeg
developers a million times.</p>
<p>I think i should redesign the whole flow then... I'm adding data
to the Signal, which comes from the view itself (it's name, or
'page title').</p>
<p>What should be the place to store information about a specific
view? A model specific to that view, or the view itself (this is
where i store the name of the view currently)?</p></div>maggelotag:robotlegs.tenderapp.com,2009-10-18:Comment/105605902011-10-12T06:26:47Z2011-10-12T06:26:47ZTwo Mediators and a command to change one...<div><p>I'm not exactly sure what you're going for here...</p>
<p>You could store a views properties/setup in a VO(value object),
that get passed to the view either by the views API or is the
constructor (DI).</p>
<p>I'm don't see how your first question applies to where you store
a views properties?</p>
<p>Can you please try to explain a bit more?</p></div>Pierre Laveklinttag:robotlegs.tenderapp.com,2009-10-18:Comment/105605902011-10-12T06:28:30Z2011-10-12T06:28:30ZTwo Mediators and a command to change one...<div><p>It's one of the hard things when starting out with RL or MVC in
particular: defining the boundaries between the different tiers and
what goes where. I know I struggled a lot with it and actually
still do.</p>
<p>Now, none of what follows is set in stone, nor is it without
exceptions, so keep that in mind.</p>
<p>In general models are used for 2 things: storing
<em>application</em> data/state and manipulating that data.<br>
It doesn't mean all data needs to be put in a model. Only data that
is shared amongst actors in the application or data that needs to
persist beyond the life cycle(s) of a(n) actor(s).<br>
Does this mean view data is never stored in models? No, but only if
it needs to be shared or needs to persist. (There are other
reasons, but let's keep it simple)<br>
So the first thing you have to ask yourself is whether the data is
shared by various actors.</p>
<p>In your case you'd say it is, since you got two mediators
accessing the same data, right?<br>
But another thing many people struggle with in the beginning is the
tendency to let all communication between elements go through the
framework/system, while in reality that's not necessary, especially
when it comes to views.<br>
In my mind application logic actually falls into one of two
categories: view logic or business/system logic. Roughly speaking
all view logic needs to go in the view tier and all business logic
goes into the other 3 tiers: model, service, controller. This is
definitely debatable and the boundaries are sometimes very blurred,
but it really helped me to start analyzing my applications with
that dichotomy in mind.</p>
<p>Now let's take a look at your case:<br>
You have 2 views coming on screen at the same navigation state. Now
this sounds to me that these 2 views are actually coupled to each
other, that one won't exist w/o the other. In my experience, every
time that happened, those two views were actually one view.<br>
A view can consist out of one display object, but it can also exist
out of hundreds. It would actually be better to think of views as
view <em>components</em>, but since component has so many meanings,
especially in flash, I try to avoid using that term. But that's
what a view basically is: a collection of display objects, all
working together <em>presenting</em> the same view data. These
display objects can have dependencies on each other and communicate
with each other, all w/o the rest of the system having any
knowledge about what's going on there.</p>
<p>So, that's the next question you need to be asking yourself: are
these really 2 separate views or actually one view with different
parts?<br>
When will it be the former? If you need to reuse one of both in a
different context (not talking about RL context), but still
accessing exactly the same data. Or if they need to exist
separately from each other. But if you realize that you'll always
be using both views together, then actually they are one view.<br>
In that case the solution is to create a containing display object
and mediate that instead of the 2 parts separately.</p>
<p>Pfioe.</p>
<p>Another thing: mediators really should be that: mediators. They
are middle men between the views and the rest of the system. They
should have no logic at all. They receive or pull data and pass it
to or pull it from their views. They relay signals from view to
system and back. And that's it.<br>
Mediators shouldn't know whether their views are transitioned in or
not, they are not view controllers.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/105605902011-10-12T18:48:53Z2011-10-12T18:48:55ZTwo Mediators and a command to change one...<div><p>Thanks for all the fast replies, love that! Sorry for the
confusion.<br>
The situation is that i have some screens (separate views and
mediators with separate functionality), and on top of some of those
views lies another view (2 'bars'. 1 topbar, 1 bottombar, in one
view with a mediator). so at times, there are 2 views and 2
mediators active (a random screen, with overlayed the bottom- and
top bars.)</p>
<p>The topbar is quite generic, it has a back button, textfield and
a settings button.<br>
the bottom bar has 4 'tab bar' navigation items.</p>
<p>What i want to achieve is that the textfield in the topbar will
display the 'name' of the view that is currently active beneath
it!</p>
<p>So, that's to make my second reply clear :) i currently store
the name of the underlying view in the view itself. is this a good
place to store the name of the view?<br>
and then, what is the best way to get it to display in another
view? since they are both coming on screen at the same time? (the
top- and bottom bars are not visible on all screens so they
transition in at the same time a view transitions in)</p>
<p>I hope my question is a lot more clear now :)</p></div>maggelo