tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/1454-is-mediator-a-good-place-to-validate-a-connected-viewRobotlegs: Discussion 2018-10-18T16:35:47Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-12T06:57:25Z2013-04-12T06:57:25ZIs mediator a good place to validate a connected view ?<div><p>It's sometimes required to perform validations, using the
information placed in the model. In this case, view themselves
cannot perform all the validations. They have to dispatch an event
, and when the event is listened by mediator ( via viewListener ) ,
it will use the view reference and the injected model to perform
all the required validations.<br>
Is it ok, to perform view-validations in mediator ?</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-12T09:03:54Z2013-04-12T09:03:54ZIs mediator a good place to validate a connected view ?<div><p>Very short answer, due to lack of time:<br>
It's a bad idea to let the Mediator validate the View :)<br>
Hopefully, Shaun or creynders, or someone else will tell you
why.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-12T09:29:43Z2013-04-12T09:29:43ZIs mediator a good place to validate a connected view ?<div><p>Ah yes, input validation. That's a tricky one.</p>
<p><strong>You definitely should <em>not</em> do it in the
mediator.</strong> Mediators should only pass data and events (in
the broad sense, not necessarily <strong>E</strong>vents) from the
system to the view and vice versa. They're the system<->view
translators, if you will.</p>
<p><strong>Preferably input validation is always done in the view
itself.</strong></p>
<p>A/ Either the mediator passes the necessary data from the model
to the view upfront, so the view can do the validation
independently, or ...</p>
<p>B/ you can create a helper class which does the validation. Then
the flow is:</p>
<ol>
<li>view dispatches event<br></li>
<li>mediator picks it up, if necessary massages the view data and
sends a new event, or it simply relays the view event to the
system<br></li>
<li>a command is triggered, collects data from the models and
instantiates a helper class, it then dispatches an event with the
result of the helper<br></li>
<li>the mediator receives the result, (translates it) and passes it
to the view</li>
</ol>
<p>C/ If you want a shortcut you can create a system-aware helper
class which does the data collecting from the models and passes it
to the mediator.</p>
<ol>
<li>view dispatches event<br></li>
<li>mediator picks it up, if necessary massages the view data and
sends a new event, or it simply relays the view event to the
system<br></li>
<li>Helper class receives the input data, collects data from the
models, validates and dispatches an event carrying the
result<br></li>
<li>the mediator receives the result, (translates it) and passes it
to the view</li>
</ol>
<p>Shortest short cut:<br>
D/ The mediator instantiates the helper class and communicates with
it directly.</p>
<p>These solutions go from cleanest (A) to dirtiest (D).</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-16T08:31:26Z2013-04-16T08:33:58ZIs mediator a good place to validate a connected view ?<div><p>Thanks for explanation Creyanders,</p>
<p>I want to ask more questions here in details... but let me start
with the basic.</p>
<p>Why i thought, it could be used because, as what i see is that
view can be injected in the mediator, so it should be freely
allowable to be used</p>
<p>Why should not i do that ? What problem i can face ? Does it
breach MVC ?</p>
<p>Correct me if i am wrong :<br>
Is it something related to "minimize" the use of injected "view"
object, because, in case the view changes, then the mediator may
need to be updated for the new "view" ??</p>
<p>Also, let's say i want to use the public variables inside the
view. What is the right approach ?<br>
1) Dispatching custom-events ( with data ) from view, and then
picking those values in the mediator<br>
2) using injected views directly, to access their public properties
and methods</p>
<p>Although Creyanders has already explained the right way, just
for understanding, is this model also not good ?<br>
( Now, I have not used validation in mediators )</p>
<p>( ATTACHED ) PS : The diagram has a typo. Please replace
myModel.validate() to myModel.storeEmail ( in the mediator )</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-16T17:42:40Z2013-04-16T17:42:40ZIs mediator a good place to validate a connected view ?<div><blockquote>
<p>Why should not i do that ?</p>
</blockquote>
<p>Because it doesn't belong there. The idea is again to maximize
reusability. If a part of your view's logic is inside the mediator
and you want to reuse the view in another project you'll need to
copy and tear the validation logic out of the mediator too. That's
why ideally all that logic is encapsulated and belongs to the view
(obviously it could still be in another, dedicated class, but the
mediator shouldn't depend on it.<br>
Also, it's a mixing of concerns. The moment you place any logic
other than passing system data and events to and from the view, the
mediator's responsibilities get muddied.<br>
If for instance later on you realize you need to reuse the mediator
for a similar (i.e. it implements the same interface) view, but w/o
the validation logic, you'll be either copying the interface and
mediator w/o that logic, but that violates DRY or you'll be moving
the logic. And so on and so on. You'll be shifting the logic around
until it finally ends where it should: the view.</p>
<blockquote>
<p>Is it something related to "minimize" the use of injected "view"
object, because, in case the view changes, then the mediator may
need to be updated for the new "view" ??</p>
</blockquote>
<p>That too. Mediators should be completely oblivious to their
view's implementation, for the reasons you state.</p>
<blockquote>
<p>Also, let's say i want to use the public variables inside the
view. What is the right approach ?</p>
</blockquote>
<p>Preferably 1. Look at it like this, your mediator needs that
data, but it also needs to know <em>when</em> to collect it. Which
means that either it is already responding to an event and then the
data can be sent along.<br>
Or it is accessing the view data immediately onRegister-time, but
what if the data is not ready yet? Right, your view'll be sending
an event. As a rule of thumb I never let a mediator access public
properties/accessors of the view.</p>
<p>But as with every rule, if you know why (and when) it's
appropriate to break it, you can break it.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-16T17:54:03Z2013-04-16T17:54:03ZIs mediator a good place to validate a connected view ?<div><p>Thanks... got it now ! :)</p>
<p>V.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-16T17:54:41Z2013-04-16T17:54:41ZIs mediator a good place to validate a connected view ?<div><p>There's a number of problems with the diagram.</p>
<ol>
<li>
<p>The validation logic doesn't belong into the model, it should be
encapsulated in a separate helper class or in the view, see posts
above.</p>
</li>
<li>
<p>You should <em>definitely</em> not use an error as a response
mechanism. Never. Errors are only meant to be used when something
goes wrong, when the application reaches an unsolvable state.</p>
</li>
<li>
<p>it's definitely not <em>that</em> mediator's responsibility to
be warning the rest of the system that it was an invalid e-mail. If
the view does the validation it sends an event which is only
relayed by the mediator. If the validation happens someplace else
(a command for instance) it's that place's responsibility to send
the event.</p>
</li>
<li>
<p>last but definitely not least, to be completely strict, it's
better not to inject models into mediators directly.</p>
</li>
</ol></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-16T18:01:59Z2013-04-16T18:01:59ZIs mediator a good place to validate a connected view ?<div><ol>
<li>=> last but definitely not least, to be completely strict,
it's better not to inject models into mediators directly.</li>
</ol>
<p>Then how to access model ? If i don't use a model there, i think
the only way is to invoke a command. Right ?</p>
<p>V.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-17T05:50:06Z2013-04-17T05:50:06ZIs mediator a good place to validate a connected view ?<div><blockquote>
<p>Then how to access model ? If i don't use a model there, i think
the only way is to invoke a command.</p>
</blockquote>
<p>Yes.
View->mediator->command->model->mediator->view.<br>
But as I wrote, that's the really strict way. And can be quite
cumbersome.</p>
<p>The e-mail validation in the diagram, is it just validating that
it's a valid e-mail address? I.e. '@' is present etc?<br>
Because if that is the case there is no reason at all to involve
the entire system. Just create a EmailValidator help class and let
the view compose it to validate the input.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-17T05:57:19Z2013-04-17T05:57:19ZIs mediator a good place to validate a connected view ?<div><p>Yeah.. cumbersome, and creates a huge crowd of files in every
folder :p</p>
<p>The email validation, was just the simplest example, i drew
quickly. Actually, in real scenario, the input needs to be checked
with the existing values inside the model ( filled in by other
views ) . I am a bit afraid of using the
view->med...->mediator->view chain, because there are many
inputs in a single view, and there are many such views in whole
application where inputs depend upon entries done in other
views.<br>
It's actually a sort of text-based-game, like facebook's
mafia-wars, or hollywood-mogul. Where validations play a key role
all over the game.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-17T12:23:59Z2013-04-17T12:23:59ZIs mediator a good place to validate a connected view ?<div><p>Sounds to me like you've distributed a lexer/parser all over the
system?<br>
Could you give a more "real", concrete example?</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-18T06:15:52Z2013-04-18T06:15:52ZIs mediator a good place to validate a connected view ?<div><p>ok.. i will share you an example/demo soon.</p>
<p>Thanks for all the help!<br>
V.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/263620722013-04-21T07:58:03Z2013-04-21T07:58:03ZIs mediator a good place to validate a connected view ?<div><p>Just added a private thread, as an extension to this one .</p></div>vishwas.gagrani