Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Mediator <=> View Component Coupling  (Read 8954 times)
riafan
Courseware Beta
Jr. Member
***
Posts: 19


View Profile WWW Email
« on: April 04, 2008, 07:08:15 »

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?
Logged
trilec
Sr. Member
****
Posts: 52



View Profile WWW Email
« Reply #1 on: April 05, 2008, 03:17:44 »

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]
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: April 05, 2008, 03:23:22 »

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>
Logged
riafan
Courseware Beta
Jr. Member
***
Posts: 19


View Profile WWW Email
« Reply #3 on: April 07, 2008, 10:38:57 »

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

Thanks Again !!!

Logged
jinglesthula
Newbie
*
Posts: 8


View Profile Email
« Reply #4 on: June 20, 2008, 10:18:11 »

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.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: June 21, 2008, 11:14:40 »

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>
Logged
Pages: [1]
Print