tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/7995-whay-we-need-mediators-in-robotlegsRobotlegs: Discussion 2014-01-06T09:43:10Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-11T12:50:25Z2013-11-11T12:50:25ZWhay we need Mediators in Robotlegs?<div><p>Hello,</p>
<p>I like the fact that you opened separate discussions for each of
your questions :)<br>
But, since they seem to be related, I'll answer all of them in
here.</p>
<p>I have a feeling that you actually know very well which are the
roles of a Mediator and when to use it, probably because you've
already read the best practices, or some tutorials, or the rl book
or went through discussions on this forum. In the context of your
other questions, I think, what you are asking is whether the MVCS
pattern is suited for games or not, right?</p>
<p>Here, a few selected links:</p>
<p>[1] games+robotlegs (you can search the forum for 'game',
'games' for more):</p>
<p><a href=
"http://knowledge.robotlegs.org/discussions/questions/759-best-practice-for-rendering-in-a-tick-game">
http://knowledge.robotlegs.org/discussions/questions/759-best-pract...</a><br>
<a href=
"http://knowledge.robotlegs.org/discussions/questions/806-is-robotlegs-slow-for-games">
http://knowledge.robotlegs.org/discussions/questions/806-is-robotle...</a><br>
<a href=
"http://knowledge.robotlegs.org/discussions/questions/468-robotlegs-as3-in-game-design">
http://knowledge.robotlegs.org/discussions/questions/468-robotlegs-...</a></p>
<p>[2] an interesting discussion on by-passing the mediator:</p>
<p><a href=
"http://knowledge.robotlegs.org/discussions/problems/222-lighter-faster-workflow-for-robotlegs-might-be-better#comment_3962484">
http://knowledge.robotlegs.org/discussions/problems/222-lighter-fas...</a></p>
<p>[3] assets loading:</p>
<p><a href=
"http://knowledge.robotlegs.org/discussions/questions/606-bitmap-handler-actor-injecting-to-view-components#comment_8770885">
http://knowledge.robotlegs.org/discussions/questions/606-bitmap-han...</a><br>
<a href=
"http://knowledge.robotlegs.org/search?q=assets&t=d&recommend=1">
http://knowledge.robotlegs.org/search?q=assets&amp;t=d&amp;recommend=1</a></p>
<p>If you decide, you don't need a Mediator, the
<strong>ViewProcessorMap</strong> will be your friend :)</p>
<p>See the readme:<br>
<a href=
"https://github.com/robotlegs/robotlegs-framework/tree/master/src/robotlegs/bender/extensions/viewProcessorMap">
https://github.com/robotlegs/robotlegs-framework/tree/master/src/ro...</a></p>
<p>especially the part about injection into views:<br>
<a href=
"https://github.com/robotlegs/robotlegs-framework/tree/master/src/robotlegs/bender/extensions/viewProcessorMap#viewinjectionprocessor">
https://github.com/robotlegs/robotlegs-framework/tree/master/src/ro...</a></p>
<p>and, other discussion on this forum:<br>
<a href=
"http://knowledge.robotlegs.org/search?q=viewProcessorMap&t=d&recommend=1">
http://knowledge.robotlegs.org/search?q=viewProcessorMap&amp;t=d&am...</a><br>
<a href=
"http://knowledge.robotlegs.org/search?q=view+processor+Map&t=d&scope=all&category_id=&recommend=1">
http://knowledge.robotlegs.org/search?q=view+processor+Map&amp;t=d&...</a></p>
<p>Let me know if it helps. Don't hesitate to ask more questions,
if need be.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-11T14:51:03Z2013-11-11T14:52:08ZWhay we need Mediators in Robotlegs?<div><p>Thanks for the links, but as the amount of the info the links
provide is really hug and in different contexts, it is difficult to
get the answer of my question. If you can explain than please tell
me why we couldn't just inject the eventDispatcher into the views,
as we do it in models and services, in order to dispatch an event
and by doing that just get rid of Mediators at all?</p></div>naghekyantag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-11T15:49:00Z2013-11-11T15:51:26ZWhay we need Mediators in Robotlegs?<div><p>Oh, ok.</p>
<p>In your config file:</p>
<pre>
<code>public class SomeConfig implements IConfig
{
[Inject]
public var viewProcessorMap:IViewProcessorMap;
[Inject]
public var commandMap:IEventCommandMap;
public function configure():void
{
viewProcessorMap.map(SomeView).toInjection();
viewProcessorMap.map(AnotherView).toInjection();
commandMap.map(SomeEvent.ANOTHER_TYPE, SomeEvent).toCommand(SomeCommand);
}
}</code>
</pre>
<p>In SomeView:</p>
<pre>
<code>[Inject]
public var sharedDispatcher:IEventDispatcher;
private function someFunction():void
{
sharedDispatcher. dispatchEvent(new SomeEvent(SomeEvent.SOME_TYPE, message));
}</code>
</pre>
<p>In AnotherView</p>
<pre>
<code>[Inject]
public var sharedDispatcher:IEventDispatcher;
private function creationCompleteHandler(event:FlexEvent):void
{
sharedDispatcher.addEventListener(SomeEvent.SOME_TYPE, onGlobalDispatch);
}
private function onGlobalDispatch(event: SomeEvent):void
{
trace(event.message);
sharedDispatcher. dispatchEvent(new SomeEvent(SomeEvent.ANOTHER_TYPE, anotherMessage));
}</code>
</pre></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-11T20:13:29Z2013-11-11T20:13:29ZWhay we need Mediators in Robotlegs?<div><p>Can I consider that you agree with me that Mediators can be
eliminated from Roboltegs at all without any losses in the great
idea of the framework? And also you have posted above and example
how I should do when I don't use mediators? So are there still
reasons why we need mediators?</p></div>naghekyantag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-12T09:09:11Z2013-11-12T09:09:11ZWhay we need Mediators in Robotlegs?<div><blockquote>
<p>Can I consider that you agree with me that Mediators can be
eliminated from Roboltegs at all without any losses in the great
idea of the framework?</p>
</blockquote>
<p>Most definitely not. Mediators allow decoupling of the views
from the rest of your system. W/o mediators your views will have
way too much knowledge about the other parts of your
application.</p>
<p>The benefits are:</p>
<p>1/ reusability. If your views are truly decoupled, it's really
easy to reuse them in a different context, application etc. All
they'll depend on are components and your message carriers (events,
signals, ...) while if your views have direct dependencies on
services, models, etc. it's a lot harder to take them out and
reuse.</p>
<p>2/ strict separation of tiers/concerns. Views should only deal
with presentation logic. They shouldn't be bothered with how and
where data comes from, they just need to take care of displaying
the data. W/o mediators this is not possible.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-12T10:57:35Z2013-11-12T11:42:48ZWhay we need Mediators in Robotlegs?<div><p>I completely agree with creyenders on the benefits of using
Mediators.</p>
<p>As a matter of fact, I chose, first PureMVC, and then Robotlegs,
as frameworks for my projects, because of the way they implement
the MVC design pattern. My projects are mostly large desktop AIR
applications + backend databases...MVCS best meets the needs of
<em>my</em> projects.<br>
Depending on the nature of a project, other design patterns might
be a better fit than MVC(S).<br>
Forcing a project into a certain pattern is not a good idea, in my
opinion. So, if you feel that MVCS is not suited for your app, use
something else. Robotlegs 2 is very flexible in this regard. I
know, I know, it is hard to decide what you need, if everything is
kind of new (the framework, the patterns).</p>
<p>A real fact from my own experience on the reusability of
views:<br>
I was working on a project in a team of developers that used
puremvc as a framework, while I was still maintaining a
robotlegs-project with a similar structure as theirs. We ended up
exchanging some components (mediated Views). The wiring of views to
mediators is different in the 2 frameworks, but it was just a
matter of a few minutes to plug our Views into the other framework,
and that only because our Views were completely decoupled from the
framework:)</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-13T07:12:29Z2013-11-13T07:12:29ZWhay we need Mediators in Robotlegs?<div><p>Fine, so both of you think kind of the same way, i.e. (citing
creyenders)</p>
<p>"Views should only deal with presentation logic. They shouldn't
be bothered with how and where data comes from, they just need to
take care of displaying the data. W/o mediators this is not
possible."</p>
<p>I agree that this decoupling is handy but in that case I cannot
understand why Models and Services should inject eventDispatcher to
dispatch events. Maybe we need some kind of mediators there too?
Well Commands partially mediate Models and Services, as far as no
one of them listens to eventDispatcher, but what about using
eventDipatcher to dispatch events. This is also a coupling and
event more, the same type of coupling.</p></div>naghekyantag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-13T08:46:13Z2013-11-13T08:46:13ZWhay we need Mediators in Robotlegs?<div><p>The EventDispatcher is a native class, so when reusing models or
services<br>
you won't need to copy it along.</p>
<p>That said, don't get me wrong: models, services and views
<em>are</em> allowed to<br>
have dependencies. In fact most of mine do, but they're always
encapsulated<br>
pieces that logically "belong" to the M, S or V. For instance: my
services<br>
tend to depend on a corresponding parser class, e.g.
TwitterFeedService<br>
depends on ITwitterFeedParser.<br>
Dependencies are only a real problem when two pieces of
functionality are<br>
logically unrelated, yet they depend on each other simply to
communicate<br>
their state. For instance, a LoginService and UserProfileView. The
only<br>
connection they have is that they use the same data (e.g. UserVO)
and it<br>
could be you want to show the user profile whenever a user has
logged in,<br>
which means there needs to be some kind of communication (chain).
Yet a<br>
LoginService should be able to function without the UserProfileView
(maybe<br>
you only want to show the user profile whenever a user clicks a<br>
"profile"-button) and vice versa (maybe you want to use
UserProfileView to show the details of other users too)<br>
If these two classes have a direct dependency it's a problem,
because<br>
they'll be tied to each other, yet both should be completely
independent<br>
from each other, since only then they're really reusable. Also,
irrelevant<br>
dependencies tend to reduce readability and robustness and muddy
the<br>
separation of concerns.</p>
<p>And getting back to the EventDispatcher, it's a messaging class,
even<br>
models and services need to be able to message their state to the
system,<br>
how would the system otherwise know when their state is
changed?</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-13T17:27:21Z2013-11-13T17:27:21ZWhay we need Mediators in Robotlegs?<div><p>Dear creynders I am talking about this syntax:</p>
<p>public class GfxLoaderService {</p>
<pre>
<code>[Inject]
public var eventDispatcher:IEventDispatcher;</code>
</pre>
<p>...........</p>
<p>This service can not be used out of RL framework as far as we
don't have mapping and injection mechanism, right?</p></div>naghekyantag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-14T08:51:43Z2013-11-14T08:51:43ZWhay we need Mediators in Robotlegs?<div><p>When used outside a RL-project the Inject-metadatatag is simply
discarded<br>
by the compiler. So, yes, you can reuse it.<br>
If you think it's ugly, you can make <code>eventDispatcher</code> a
constructor<br>
parameter, then you don't need the Inject-tag.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-15T08:49:10Z2013-11-15T08:49:10ZWhay we need Mediators in Robotlegs?<div><p>If I make <code>eventDispatcher</code> a constructor parameter,
then how can I pass the <code>eventDipstacher</code> which creates
RL to the constructor?</p></div>naghekyantag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-15T09:31:17Z2013-11-15T09:31:17ZWhay we need Mediators in Robotlegs?<div><p>The shared event dispatcher is available <strong>after</strong>
context's initialization. It has already a mapping, so that you can
do this in your class that needs it as a constructor argument:</p>
<pre>
<code>public class SomeModel
{
private var _someProperty:String;
private var _eventDispatcher:IEventDispatcher;
public function SomeModel(eventDispatcher:IEventDispatcher)
{
_eventDispatcher = eventDispatcher;
}
public function get someProperty():String
{
return _someProperty;
}
public function set someProperty(value:String):void
{
_someProperty = value;
_eventDispatcher.dispatchEvent(new SomeEvent(SomeEvent.SOME_TYPE, value+" greetings from model"));
}
}</code>
</pre></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-15T10:18:48Z2013-11-15T10:34:36ZWhay we need Mediators in Robotlegs?<div><p>And in in context configurations I need to map it like this?</p>
<p>[Inject] public var eventDispatcher : IEventDispatcher;</p>
<p>public function configure() : void {<br>
var someModel:SomeModel= new SomeModel(eventDispatcher );
injector.mapValue(SomeModel, someModel); }</p>
<p>There is no way to map as a singleton with explicit call of a
constructor with desired arguments, is there?</p></div>naghekyantag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-15T10:34:20Z2013-11-15T10:34:20ZWhay we need Mediators in Robotlegs?<div><p>Every thing that is in constructor will be injected if you use
injector to create that class.</p></div>matejtag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-15T10:35:31Z2013-11-15T11:05:13ZWhay we need Mediators in Robotlegs?<div><p>No, not like that:)</p>
<p>you map your Model in a config class that implements IConfig
like so:</p>
<pre>
<code>public class ModelsConfig implements IConfig
{
[Inject]
public var injector:IInjector;
public function configure():void
{
injector.map(SomeModel).asSingleton();
}
}</code>
</pre>
<p>In your class where you create your Context:</p>
<pre>
<code>context = new Context()
.install(MVCSBundle)
.configure(ModelsConfig)
.configure(new ContextView(view));</code>
</pre>
<p>Context's ExtensionInstaller installs all the extensions
contained in a given class that implements IBundle, meaning that
you can create your custom bundle, if you want to.<br>
The MVCSBundle installs a number of extensions commonly used in
typical Robotlegs applications and modules.<br>
EventDispatcherExtension is included in the MVCSBundle.</p>
<p>The IEventDispatcher is mapped like so:</p>
<p><a href=
"https://github.com/robotlegs/robotlegs-framework/blob/master/src/robotlegs/bender/extensions/eventDispatcher/EventDispatcherExtension.as#L55">
https://github.com/robotlegs/robotlegs-framework/blob/master/src/ro...</a></p>
<p>If you don't have the EventDispatcherExtension installed, for
some reasons, you have to map the IEventDispatcher yourself before
injecting it through [Inject] or as a constructor argument into
your classes.</p>
<p>If you want an additional dispatcher, you can use named
injections:</p>
<pre>
<code>var specialDispatcher:IEventDispatcher = injector.getInstance(IEventDispatcher);
injector.map(IEventDispatcher, "specialDispatcher").toValue(specialDispatcher);</code>
</pre>
<p>Injected like this:</p>
<pre>
<code>[Inject (name="specialDispatcher")]
public var specialDispatcher:IEventDispatcher;</code>
</pre></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-15T10:40:57Z2013-11-15T10:40:57ZWhay we need Mediators in Robotlegs?<div><p>@matej</p>
<blockquote>
<p>Every thing that is in constructor will be injected if you use
injector to create that class.</p>
</blockquote>
<p>Right.<br>
But the Injector needs a rule for the constructor arguments as
well.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-15T10:57:00Z2013-11-15T10:57:00ZWhay we need Mediators in Robotlegs?<div><p>[PostConstruct] public function init():void{<br>
//all other mappings injector.map(SomeModel).asSingleton();<br>
}</p></div>matejtag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-15T11:14:52Z2013-11-15T11:14:52ZWhay we need Mediators in Robotlegs?<div><p>I think, the inherited configure() comes in very handy. I don't
need to write yet another metatag ;)</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/299105722013-11-15T11:46:27Z2013-11-15T11:46:27ZWhay we need Mediators in Robotlegs?<div><p>I agree :)</p></div>matej