tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/7887-logic-in-mediatorsRobotlegs: Discussion 2013-12-23T09:22:49Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/303599772013-12-05T05:02:57Z2013-12-05T05:02:58ZLogic in Mediators<div><p>is any one there???</p></div>Pratiktag:robotlegs.tenderapp.com,2009-10-18:Comment/303599772013-12-05T11:10:46Z2013-12-05T11:11:34ZLogic in Mediators<div><p>Hello Pratik,</p>
<blockquote>
<p>is any one there???</p>
</blockquote>
<p>I'm here now:) But, you have to know, we (staff members) can't
be present on the forum all the time(24/7), because ... well, first
of all, we need to sleep as any other humans ;) We also work for a
living , have families..e.t.c. We do our best to respond as soon as
possible, though.</p>
<p>I'm not going to get into all the details and repeat all that's
been already said, because it would take me too long. Hopefully,
others will chime in and add their own opinions on the topic.</p>
<p>If you've been reading through the discussions on this forum
about Mediators, as you said, then you've noticed that the main
keywords are:</p>
<p>a - reusability<br>
b - portability<br>
c - loose coupling<br>
d - single responsibility principle (SPR) , separation of
concerns</p>
<p>Following those principle while designing your Views/Mediators
allows you to:</p>
<ul>
<li>
<p>reuse same views in different application ( for example a
LoginView)</p>
</li>
<li>
<p>use the same logic for other platforms / languages</p>
</li>
<li>
<p>use the same view with other frameworks or other design
patterns</p>
</li>
<li>
<p>build modular applications</p>
</li>
<li>
<p>improve the readability of the code, its maintainability and to
write testable code</p>
</li>
</ul>
<p>A Mediator should not keep state of its View. It is not meant to
act as "code-behind"<br>
Its role is to "mediate" - to act <strong>between</strong> parties
( between the View as a user interface and the rest of the
application). If the Mediator is doing more than that, that's a
sign that you either need another pattern (Presenter, for example)
or you don't know enough about Mediator's responsibilities at the
moment.</p>
<p>Having 3000 - 5000 lines of code in any class, not only in a
Mediator is bad, in my opinion. 5000 LOC in a Mediator could also
be a sign that the mediated View is too large and it's time to
split it into several Views, each of them with a designated role
and its own Mediator. It might be very important especially when
building a mobile app!!</p>
<p>It is easier to reuse a Mediator in a mobile application, if it
is only listening for custom events or Signals dispatched by the
View . Whether it is a Mouse click event or a Touch event , the
Mediator should not care, it only reacts to a custom event or a
Signal emitted in the handler of Mouse or Touch event.</p>
<p>Here, just a summary of all that's been already discussed on
this forum and been said in books, Best-practices articles, about
MVCS-Actors' roles:<br>
<a href=
"http://knowledge.robotlegs.org/discussions/problems/3815-injector-is-missing-a-mapping-to-handle-injection-into-property#comment_28949774">
http://knowledge.robotlegs.org/discussions/problems/3815-injector-i...</a></p>
<p>I highly recommend to read some of, or all, the articles/books
listed bellow, before making a presentation.</p>
<p>Recommended readings:</p>
<p><strong>General</strong></p>
<p>[1] Gang of Four - Design Patterns: Elements of Reusable
Object-Oriented Software: - <a href=
"http://c2.com/cgi/wiki?MediatorPattern">http://c2.com/cgi/wiki?MediatorPattern</a></p>
<p>[2] Clean Code: A Handbook of Agile Software Craftsmanship: -
<a href=
"http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882">
http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/...</a></p>
<p>[3] Code Complete: A Practical Handbook of Software
Construction: - <a href=
"http://www.amazon.com/dp/0735619670/?tag=stackoverfl08-20">http://www.amazon.com/dp/0735619670/?tag=stackoverfl08-20</a></p>
<p><strong>Actionscript</strong></p>
<p>[4] <a href=
"http://joelhooks.com/2011/03/12/an-introduction-to-robotlegs-as3-part-1-context-and-mediators/">
http://joelhooks.com/2011/03/12/an-introduction-to-robotlegs-as3-pa...</a></p>
<p>[5] Robotlegs Best-Practices: - <a href=
"https://github.com/robotlegs/robotlegs-framework/wiki/Best-Practices#wiki-mediators">
https://github.com/robotlegs/robotlegs-framework/wiki/Best-Practice...</a></p>
<p>[6] ActionScript Developer’s Guide to Robotlegs: -
<a href="http://shop.oreilly.com/product/0636920021216.do">http://shop.oreilly.com/product/0636920021216.do</a></p>
<p>[7] ActionScript Developer's Guide to PureMVC: - <a href=
"http://shop.oreilly.com/product/0636920022459.do">http://shop.oreilly.com/product/0636920022459.do</a></p>
<p>[8] ActionScript 3.0 Design Patterns - <a href=
"http://www.oreilly.de/catalog/9780596528461/">http://www.oreilly.de/catalog/9780596528461/</a>
- <a href="http://www.as3dp.com/">http://www.as3dp.com/</a></p>
<p>[9] Adobe Cairngorm 3 - Guidelines: - <a href=
"http://sourceforge.net/adobe/cairngorm/wiki/CairngormGuidelines/">http://sourceforge.net/adobe/cairngorm/wiki/CairngormGuidelines/</a></p>
<p><strong>LOC</strong> (lines of code)</p>
<p>[10] Cyclomatic complexity: <a href=
"http://en.wikipedia.org/wiki/Cyclomatic_complexity">http://en.wikipedia.org/wiki/Cyclomatic_complexity</a></p>
<p>[11] <a href=
"http://stackoverflow.com/questions/20981/how-many-lines-of-code-is-too-many">
http://stackoverflow.com/questions/20981/how-many-lines-of-code-is-...</a></p>
<p>[12] <a href=
"http://programmers.stackexchange.com/questions/185925/how-important-is-it-to-reduce-the-number-of-lines-in-code">
http://programmers.stackexchange.com/questions/185925/how-important...</a></p>
<p>[13] <a href=
"http://programmers.stackexchange.com/questions/155488/ive-inherited-200k-lines-of-spaghetti-code-what-now">
http://programmers.stackexchange.com/questions/155488/ive-inherited...</a></p>
<p>hth</p>
<p>Cheers,<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/303599772013-12-05T12:33:13Z2013-12-05T12:33:13ZLogic in Mediators<div><p>I didnt mean to offend you guys.Of course you have other
responsibilities ,Its just i was not sure of time zone and wanted
to only confirm whether i reached you guys .<br>
I will go through the Presenter Model and see if it suits my
requirements.<br>
Thank -you for support. :)</p></div>Pratiktag:robotlegs.tenderapp.com,2009-10-18:Comment/303599772013-12-05T12:42:34Z2013-12-05T12:42:34ZLogic in Mediators<div><p>No offense taken :)<br>
Good luck with your presentation!</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/303599772013-12-06T10:15:52Z2013-12-06T10:15:52ZLogic in Mediators<div><p>Sorry Pratik,</p>
<p>I didn't have time to react earlier. Ondina's quite right.
Mediators aren't meant as code-behind, although many people seem to
interpret them that way.</p>
<p>The main idea of mediators is to provide easy reuse of views
(through decoupling). The views should be totally system (i.e.
application) agnostic AND framework (i.e. Robotlegs) agnostic.
That's the only way to ensure you can take a view from one project
and paste into another w/o too much hassle. Mediators on the other
hand are the "glue" between the views and the rest of the system.
I.e they concretisize the semi-abstract views. This means that
mediators have a lot of system-knowledge; they access models,
concrete system events, maybe even services (more on this
later)<br>
However, if a view can't exist w/o its mediator (since it contains
view logic) it becomes problematic to reuse the view. You can't
just take the view out of the project and paste it into another
once, since it needs the mediator too. But. If you paste the
mediator along with the view you'll be adding a lot of the
application-specific knowledge to your new project, which means
you'll be hunting down those application-specific references inside
the mediator. Good luck with that in a mediator of 5000 LOC. (5000?
Seriously? Wow.... Again, more on that later on)</p>
<p>There's one correction to Ondina's (no offense!) explanation I'd
like to make: even when using the Presenter pattern you'll need
mediators. Maybe even more so, since the presentation model needs
to be assembled somewhere, you could do this in commands, but in
effect you'll be actually creating short-lived mediating fragments.
It's far easier to do this in a mediator (when using the Presenter
pattern !! Not in "normal", recommended RL usage)</p>
<p>Then, should mediators access models, services, etc? Yes and
no.<br>
I know, that's not really helpful. But this is a situation in which
you need to have some experience to know when to stick to best
practice (=no direct access to models and services in mediators)
and when to break it. In general, as a rule of thumb, try to avoid
it as much as possible. <strong>Views (and in extension mediators)
shouldn't be aware of the source of data, nor even whether the data
is already there or is loaded/generated on the fly.</strong><br>
It's a bit hard to explain, but you'll notice that if you keep that
rule of thumb in mind, you'll be creating far more versatile and
reusable views and mediators.<br>
For example: you have a mediator which calls a service directly and
uses its output in the view. Then later on, requirements change,
and you realize you need that same data someplace else. That's
where trouble starts to kick in. Maybe the data needs to be loaded
before the view is added to the stage (i.e. the mediator doesn't
exist yet) or the data needs some massaging before its put in the
model and can be consumed by the view. These requirements will
force you to start hacking around or to rewrite your mediator
entirely.</p>
<p>Last, but definitely not least. 5000 LOC in a file is just ...
gruesome. It's <em>the</em> #1 rule: keep your classes short and
sweet and let them have 1 responsibility (SRP) Only one. You'll be
avoiding a world of pain. A world of pain, I say ;)</p>
<p>My long 2 cents.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/303599772013-12-06T10:39:44Z2013-12-06T10:39:44ZLogic in Mediators<div><p>Hi Creynders,<br>
No need to apologize,you guys are doing a fantastic job.Yeah, these
mediators here are a mess...i have been banging around my head so
hard but still am not able to get a clear idea of the workings
since the Models are accessed from practically everywhere in a
Mediator.There is no single Point of Access or a Pattern to the
Work Flow.The Commands are completely bypassed and all the model
/service data manipulation is done in mediators. To make My Life a
living hell the guys earlier have used Global variables
everywhere(Classes with static variables). Now am assigned to clean
up this mess.<br>
Thank-you for the insight.<br>
Again appreciate the swift and useful support you guys provide.<br>
Cheers</p></div>Pratiktag:robotlegs.tenderapp.com,2009-10-18:Comment/303599772013-12-06T10:48:13Z2013-12-06T10:48:13ZLogic in Mediators<div><blockquote>
<p>There's one correction to Ondina's (no offense!) explanation I'd
like to make: even when using the Presenter pattern you'll need
mediators.</p>
</blockquote>
<p>Yeah, sorry for not being clear. What I had in mind was
Presentation Model used like in Joel's demo:<br>
<a href=
"https://github.com/joelhooks/robotlegs-examples-ImageGalleryPM">https://github.com/joelhooks/robotlegs-examples-ImageGalleryPM</a></p></div>Ondina D.F.