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: Yo Cliff! Why the connection between the mediator and the proxy?  (Read 17923 times)
Public
Courseware Beta
Newbie
***
Posts: 6


View Profile Email
« on: May 29, 2008, 11:28:05 »

We are having a heated nerd debate about why there is a connection between the mediator and the proxy, as this connection potentially promotes ignoring the control/command tier. If you could enlighten us as to when you see this as being a good connection to have and when it is a bad connection to have, we would appreciate your time.

Our implementation is in AS3, using iResponder to return the details of the transaction

Thanks!

Logged
Public
Courseware Beta
Newbie
***
Posts: 6


View Profile Email
« Reply #1 on: May 29, 2008, 11:48:29 »

There is a post where folks are discussing this already, kind of sums it up well, but it still begs the question... do you want mediators seting in proxies instead of enforcing that kind of interaction through commands? If it is a simple getter setter, why can't it be a well abstracted get command /set command?

discuss...
« Last Edit: May 29, 2008, 11:53:56 by Public » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: May 31, 2008, 09:49:44 »

The simple rational is that often we see an explosion of Commands which do nothing but set a piece of data on the model, get it and forward it, or call a method.

These commands are often triggered by notification from the view, which in other frameworks often has no insulating layer such as the Mediator offers. I understand Cairngorm has deprecated the ViewHelper, which is the closest analog to the Mediator there. In a system like that, you have no choice to build lots of Commands to keep that logic out of the view.

However, as notification participants with access to the Facade, Mediators are just as able to retrieve a Proxy and set data upon it or visa versa as is a Command. And after all, the view has no reason for existence other than representing the Model and allowing the user to interact with it, so it isn't unreasonable that the Mediator, having done its job of keeping any deep model knowledge from its view component and visa versa, should be on speaking terms with the model.

Creating a Notification to tell the Command to do the work when the Mediator can do so without breaking any of the collaboration patterns available to it makes sense only in one situation - when you want that action to be triggered from different places in the view.

For instance if you have a Command that simply calls a Proxy method, but you want to trigger that action from a popup menu, a keyboard shortcut and perhaps sometimes programatically, then a Command is your friend. It will centralize that simple call so that if the Proxy method name changes, for instance, you need only modify that one Command.

However, at least 80% of the time, the data in the Proxy is exposed and manipulated at a single location in the view. The view is broken into components and the components have Mediators that connect them to the application and broker all communication with it.

The view component is separated from the Model and the Model is separated from the view. No need to bring in yet another actor and pass a message to it in the name of abstraction and good separation. The desired separation has already been made.

In the example above of triggering a simple call from multiple places, it is only necessary to bring the Command into the picture once the second use case for triggering the action has been added to the application. If to begin with you could only trigger it from the Menu component, and the MenuMediator gets the data from the menu on an event, it can immediately perform the Proxy call. This is the shortest path. It takes the fewest processor cycles to execute, is the easiest for the next programmer to follow, and no bad OOP juju has been spilled.

But in the next version, keyboard shortcuts and macro playback have been added to the requirements. Now we know this same thing that was happening in the menu will happen in other places so we refactor the Mediator to Proxy call into a Command as the first step, trigger it from the Mediator to be sure it works, and then set about adding the new functionality to call it from elsewhere in the view.

Allow the complexity to creep in only where necessary. Thinking ahead to be 'strict' is often a way of getting cart before horse. Knowing you'll need something down the line doesn't mean you have to build it in now, just that your actions shouldn't preclude it.

-=Cliff>
Logged
Public
Courseware Beta
Newbie
***
Posts: 6


View Profile Email
« Reply #3 on: June 06, 2008, 04:51:46 »

thank you for the in depth response, Cliff.
Logged
2domby
Newbie
*
Posts: 2


View Profile Email
« Reply #4 on: September 26, 2008, 07:58:05 »

Hey Cliff, that was the most important, interessting and helpful explanation I have read in this forums so far! Thank's a lot, that helped me a lot!! Yeah!!! ;D

Now I can go on building my world app ...  :D
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #5 on: October 03, 2008, 05:58:05 »

Hey Cliff, that was the most important, interessting and helpful explanation I have read in this forums so far! Thank's a lot, that helped me a lot!! Yeah!!! ;D

Now I can go on building my world app ...  :D

Damn, I've been using PureMVC for almost a year now and somehow missed this post. It even made things clearer to me,and I thought I already understood most or the intricacies of PMVC. Goes to show you can always learn something new... or understand it better at least!

Thanks Cliff!
Logged
MAXOUT
Newbie
*
Posts: 2


View Profile Email
« Reply #6 on: September 30, 2010, 06:42:46 »

agree. grow step by step.
What I have done in steps:
  1, all logic in the view, only for trial;
  2, have a clean view and move others to the mediator;
  3, have a clean mediator again, move others like database access to proxy;
  4, then at last using a command for a complex situation.
I was not sure using these in different situations at the beginning. But having in my mind that step 4 costs the most. And I need to confirm my thought, which this post does.
Cheers
Logged
Pages: [1]
Print