Is mediator a good place to validate a connected view ?

vishwas.gagrani's Avatar

vishwas.gagrani

12 Apr, 2013 06:57 AM

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 ?

  1. Support Staff 1 Posted by Ondina D.F. on 12 Apr, 2013 09:03 AM

    Ondina D.F.'s Avatar

    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.

  2. Support Staff 2 Posted by creynders on 12 Apr, 2013 09:29 AM

    creynders's Avatar

    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:

    1. view dispatches event
    2. 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
    3. 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
    4. the mediator receives the result, (translates it) and passes it to the view

    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.

    1. view dispatches event
    2. 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
    3. Helper class receives the input data, collects data from the models, validates and dispatches an event carrying the result
    4. the mediator receives the result, (translates it) and passes it to the view

    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. 3 Posted by vishwas.gagrani on 16 Apr, 2013 08:31 AM

    vishwas.gagrani's Avatar

    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 )

  4. Support Staff 4 Posted by creynders on 16 Apr, 2013 05:42 PM

    creynders's Avatar

    Why should not i do that ?

    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.

    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" ??

    That too. Mediators should be completely oblivious to their view's implementation, for the reasons you state.

    Also, let's say i want to use the public variables inside the view. What is the right approach ?

    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. 5 Posted by vishwas.gagrani on 16 Apr, 2013 05:54 PM

    vishwas.gagrani's Avatar

    Thanks... got it now ! :)

    V.

  6. vishwas.gagrani closed this discussion on 16 Apr, 2013 05:54 PM.

  7. creynders re-opened this discussion on 16 Apr, 2013 05:54 PM

  8. Support Staff 6 Posted by creynders on 16 Apr, 2013 05:54 PM

    creynders's Avatar

    There's a number of problems with the diagram.

    1. 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.

    2. 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.

    3. 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.

    4. last but definitely not least, to be completely strict, it's better not to inject models into mediators directly.

  9. 7 Posted by vishwas.gagrani on 16 Apr, 2013 06:01 PM

    vishwas.gagrani's Avatar
    1. => last but definitely not least, to be completely strict, it's better not to inject models into mediators directly.

    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.

  10. Support Staff 8 Posted by creynders on 17 Apr, 2013 05:50 AM

    creynders's Avatar

    Then how to access model ? If i don't use a model there, i think the only way is to invoke a command.

    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.

  11. 9 Posted by vishwas.gagrani on 17 Apr, 2013 05:57 AM

    vishwas.gagrani's Avatar

    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.

  12. Support Staff 10 Posted by creynders on 17 Apr, 2013 12:23 PM

    creynders's Avatar

    Sounds to me like you've distributed a lexer/parser all over the system?
    Could you give a more "real", concrete example?

  13. 11 Posted by vishwas.gagrani on 18 Apr, 2013 06:15 AM

    vishwas.gagrani's Avatar

    ok.. i will share you an example/demo soon.

    Thanks for all the help!
    V.

  14. 12 Posted by vishwas.gagrani on 21 Apr, 2013 07:58 AM

    vishwas.gagrani's Avatar

    Just added a private thread, as an extension to this one .

  15. vishwas.gagrani closed this discussion on 21 Apr, 2013 07:58 AM.

  16. vishwas.gagrani re-opened this discussion on 29 Apr, 2013 06:32 AM

  17. vishwas.gagrani closed this discussion on 29 Apr, 2013 06:42 AM.

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