PureMVC Architects Lounge

In many of the demos I've seen the mediators are directly referencing components [TextInputs for example] within the view. 

Would it be better decoupling to have the view pass the corresponding VO *with* the Event as opposed to having the mediator catch the event, and then "dig into" the view component to "pull out" the desired data (i.e. construct a VO from components w/in the view component)?

Just wondering.

The mediators seem to be so tightly coupled to the view components.  Are more verbose events worth the effort or am I being too anal?

Hi Riafan,
It my understanding that components can exchange data with the mediator using events or custom typed Objects.
so using a VO should be fine and sounds like better for your requirements (which is what its all about :-) )

Curtis [Trilec]

The mediator and view component are necessarily coupled. A given Mediator will only be used for mediating communications between a given view component and the rest of the system.

That said, it is up to you to choose the tightness of the coupling. The most loosely coupled way is, as you say, to exchange that data using a custom object or VO, passed to the mediator via a custom event.

From the Best Practices document (page 25):

A Mediator usually has only one View Component, but it might manage several, such as an ApplicationToolBar and its contained buttons or controls. We can contain a group of related controls (such as a form) in a single View Component and expose the children to the Mediator as properties. But it is best to encapsulate as much of the component’s implementation as possible. Having the component exchange data with a custom typed Object is better.

If you create a view component that is simple, and it only has one or two properties that the mediator needs access to, then creating a custom event AND a VO is overkill. A more reasonable balance between coupling and complexity (number of files involved in this case) is to simply create public properties that are considered the 'API' exposed to the mediator. Inside the view component, bind the text fields (or whatever subcomponents) data to these properties such that when an event is dispatched, the mediator inspects these API fields (not the text boxes).

If the view component has many properties to be passed, you can still avoid creating a custom event by having a single complex object (VO) as an exposed property, dispatch the event and allow the mediator to access the VO property.

Again, I am not saying that you should not do as you suggest; creating a custom event to carry the data, only that there is a balance between complexity and coupling to be made with each mediator/view component pair. But I am agreeing with you whole heartedly that the mediator should not be so intimate with a view component as to know its children and access them directly. This limits our ability to refactor the view component's internal implementation without also refactoring the mediator.

-=Cliff>

Great,
  Thanks so much for the thorough replies.  Just wanted some re-assurance I was thinking about this correctly.

Thanks Again !!!

Good stuff and helpful.  Cliff, would you recommend having the mediator set the currentState property, or having named constants for states and a public function that accepts such a const and uses a switch statement to set the view?  About the only advantage in refactoring is if you change the state names I would think.

I think the Mediator should set the currentState property of the view component to a named constant defined in the view component class. This can later be turned into an implicit getter in the view component if any logic needs to happen inside that black box, and the Mediator will not need to be refactored.

-=Cliff>