Is mediator a good place to validate a connected view ?
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.
Is it ok, to perform view-validations in mediator ?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Ondina D.F. on 12 Apr, 2013 09:03 AM
Very short answer, due to lack of time:
It's a bad idea to let the Mediator validate the View :)
Hopefully, Shaun or creynders, or someone else will tell you why.
Support Staff 2 Posted by creynders on 12 Apr, 2013 09:29 AM
Ah yes, input validation. That's a tricky one.
You definitely should not do it in the mediator. Mediators should only pass data and events (in the broad sense, not necessarily Events) from the system to the view and vice versa. They're the system<->view translators, if you will.
Preferably input validation is always done in the view itself.
A/ Either the mediator passes the necessary data from the model to the view upfront, so the view can do the validation independently, or ...
B/ you can create a helper class which does the validation. Then the flow is:
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.
Shortest short cut:
D/ The mediator instantiates the helper class and communicates with it directly.
These solutions go from cleanest (A) to dirtiest (D).
3 Posted by vishwas.gagrani on 16 Apr, 2013 08:31 AM
Thanks for explanation Creyanders,
I want to ask more questions here in details... but let me start with the basic.
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
Why should not i do that ? What problem i can face ? Does it breach MVC ?
Correct me if i am wrong :
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" ??
Also, let's say i want to use the public variables inside the view. What is the right approach ?
1) Dispatching custom-events ( with data ) from view, and then picking those values in the mediator
2) using injected views directly, to access their public properties and methods
Although Creyanders has already explained the right way, just for understanding, is this model also not good ?
( Now, I have not used validation in mediators )
( ATTACHED ) PS : The diagram has a typo. Please replace myModel.validate() to myModel.storeEmail ( in the mediator )
Support Staff 4 Posted by creynders on 16 Apr, 2013 05:42 PM
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.
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.
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.
That too. Mediators should be completely oblivious to their view's implementation, for the reasons you state.
Preferably 1. Look at it like this, your mediator needs that data, but it also needs to know when to collect it. Which means that either it is already responding to an event and then the data can be sent along.
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.
But as with every rule, if you know why (and when) it's appropriate to break it, you can break it.
5 Posted by vishwas.gagrani on 16 Apr, 2013 05:54 PM
Thanks... got it now ! :)
V.
vishwas.gagrani closed this discussion on 16 Apr, 2013 05:54 PM.
creynders re-opened this discussion on 16 Apr, 2013 05:54 PM
Support Staff 6 Posted by creynders on 16 Apr, 2013 05:54 PM
There's a number of problems with the diagram.
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.
You should definitely 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.
it's definitely not that 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.
last but definitely not least, to be completely strict, it's better not to inject models into mediators directly.
7 Posted by vishwas.gagrani on 16 Apr, 2013 06:01 PM
Then how to access model ? If i don't use a model there, i think the only way is to invoke a command. Right ?
V.
Support Staff 8 Posted by creynders on 17 Apr, 2013 05:50 AM
Yes. View->mediator->command->model->mediator->view.
But as I wrote, that's the really strict way. And can be quite cumbersome.
The e-mail validation in the diagram, is it just validating that it's a valid e-mail address? I.e. '@' is present etc?
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.
9 Posted by vishwas.gagrani on 17 Apr, 2013 05:57 AM
Yeah.. cumbersome, and creates a huge crowd of files in every folder :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.
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.
Support Staff 10 Posted by creynders on 17 Apr, 2013 12:23 PM
Sounds to me like you've distributed a lexer/parser all over the system?
Could you give a more "real", concrete example?
11 Posted by vishwas.gagrani on 18 Apr, 2013 06:15 AM
ok.. i will share you an example/demo soon.
Thanks for all the help!
V.
12 Posted by vishwas.gagrani on 21 Apr, 2013 07:58 AM
Just added a private thread, as an extension to this one .
vishwas.gagrani closed this discussion on 21 Apr, 2013 07:58 AM.
vishwas.gagrani re-opened this discussion on 29 Apr, 2013 06:32 AM
vishwas.gagrani closed this discussion on 29 Apr, 2013 06:42 AM.