View vs. Mediator: What code goes where? What, exactly, should a View do?

[Jason Tuttle]

Hi All,

I was wondering what the consensus here was regarding the division of labor between a View and its Mediator. In other words, what should the View be responsible for and what should the Mediator take care of?

1. If a View has a form, should the View validate the form or should the Mediator do it?
2. Should the View be able to reset the form? I was doing some forum searches and I came across this thread: http://forums.puremvc.org/index.php?topic=175.0 In it, Cliff seems to advocate having the View take care of reseting its own form.
3. What about printing? Should the View be able to print itself?

Thanks in advance for your thoughts...

: )

Jason

[puremvc]

Encapsulate the behaviors of the view as much as possible. Try not to make the mediator do .NET style 'code-behind' where the component is dumb and the code-behind class contains the logic. A view component should be written in such a way that it could be used elsewhere even without a PureMVC mediator behind it.

This leaves the mediator to do jus that; mediate. Take events from the component and turn them into notifications for the rest of the system, or to take notes of interest and respond by setting data on the component or calling methods on it to change its state or otherwise alert it of the system's desires where it is concerned. And occasionally to create mediators for the view component's chindren. That's about it for mediator responsibilities.

-=Cliff>   

[Jason Tuttle]

Thanks Cliff! -- Great clarification.

Much appreciated,

: )

Jason

[myIP]

Hello, Cliff you replied to Jason:

“Try not to make the mediator [my emphasis] do .NET style 'code-behind' where the component is dumb and the code-behind class contains the logic.”

This makes sense in the context of the question Jason asked (what is the purpose of a View and Mediator), however do you prefer in an addition to Mediators, we have code-behinds for Views?  So there would be 3 players in this question, the View, the code-behind and the Mediator.

The View would take care of cosmetic logic, such as to reset a form after its been submitted and perhaps tween effects.  The code-behind would take care of functional logic such as, bundling up the form data and propagating the event to the Mediator, which in turn will send its notification to the application and may call something on one of its other View components.

The reason why I ask, I wouldn't think that it will be ideal to shoe-horn cosmetic and functional logic all in the View component (MXML file).  But then again I wrote whats above a week ago, so I am really unsure.

Cliff, thanks so much for your time.

[puremvc]

Just because a component is defined in MXML doesnet mean that adding logic to it is 'shoehorning'. Its a class like any other class - an actor whose behavior and logic should be encapsulated according to ordinary OOP principles.

In the earliest days of Flex, we couldn't ASDoc an MXML file, and this lead to a lot of folks, myself included, to argue for code-behind in the view.

But that is no longer the case, and I can see no valid reason for using code-behind to break a component's encapsulation and hamper its portability.

The view components have the highest potential for re-use, and when you unnecessarily lobotomize a view component and put its brain in a vat then you have an to take that vat along with you everywhere you go. Imagine you create a view component that does a special kind of charting. You are building it for a specific app, but you realize that it could be widely re-usabe (perhaps even marketable) if you play your cards right. In your app, maybe you're using PureMVC, but users of cairngorm, mate, swiz, fizz, floop, flop and flap do things differently. But the one thing common to us all is that we often have to take off the shelf components and adapt them to our systems. If your component is fully self contained and exposes a simple API of events, methods and properties then you'll find it easy to make everyone happy because it's dirt simple to drop in and use.   

And consider the situation being reversed. You find yourself charged with dropping someone elses component into your app and making it work. This is how most COTS components you find will work, so if you're doing code-behind in your own components, you'll be faced with a disparity in the implementation of your system when it comes to this component, you'll just wrap a mediator around it, listen for events and set data and call methods on it.

If you look at how Flex itself is built, you don't see code behind in components.You see encapsulated classes. In building upon all this why would we decide to break encapsulation of our own components?

-=Cliff>

[myIP]

At the time I posted, I failed to realize that MXML components can inherit from other custom components.  Perhaps, I thought MXML components were different in some way then a class file.  Which is strange, since I always poke around in the generated files.  Thanks for clearing that question up.