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: Best practice: Send more notifications from commands or use mediator functions?  (Read 3351 times)
midget35
Newbie
*
Posts: 5


View Profile Email
« on: July 12, 2011, 02:50:33 »

Hi,

If I have a command called 'SetReadyOnlyMode', is it OK for me to access public methods on mediators from that command and pass some properties? Or should I be firing another batch of notifications from that command to be picked up by the mediators?

The component views are disabled depending on some values in different proxies, so in my command I want to do this:
:
if (!userProxy.getAlwaysShowToolbars()){
   toolbarMediator1.hideView();
   toolbarMediator2.hideView();
}

if (userProxy.contactListContains(friendProxy.friendIDs)){
  friendListMediator.showView(friendProxy.friendIDs);
} else { // ... hide friendList ... }

 

Does this seem a good way to do it? Can commands 'directly' interact with mediators like this, and pass arguments etc.? Otherwise I'm worried I'll have bloated code as a result of too many notification string constants all with similar tasks.

Many thanks for any help!
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 13, 2011, 07:44:00 »

You can expose methods on Mediators and invoke them from Commands, but it is a better practice to use notifications if you can. Loose-coupling is a best practice for OOP in general, and within PureMVC this is the primary way we achieve it.

In your example, you are only performing a one-way communication from the Command to the Mediator. Wherever this is the case, you can and should reduce the coupling by sending notifications. This also allows for other actors to also trigger the same functionality in a loosely-coupled way. For instance, it isn't uncommon to find that you want to trigger the same functionality from a menu item, a keyboard shortcut, a button and the Undo utility. But you may not know all those requirements exist at the beginning, they get heaped on later. If your Mediator is set up to receive a note, then the various Commands and Mediators that would otherwise need to collaborate directly (via import and method invocation) with the key Mediator need only send a note. Less spaghetti.

You still may find you really have to import a Mediator and work with it when the logic of the Command requires a value returned from the Mediator, or you need a synchronous two-way conversation. For instance, I am working on an application that has a desktop viewer based on WindowedApplication and a web viewer based on Application. There is shared code that often needs to adjust its behavior based on we're running on the web viewer or the desktop viewer. In a ViewerType class, I defined constants for WEB and DESKTOP. And the applications implement an interface that requires a getter and setter for a viewerType property that is initialized to the appropriate constant. Then when a Command needs to know the viewer type, it retrieves the ApplicationMediator and reads a viewerType implicit getter which exposes the setting on the app. That way the command consults the Mediator but does not need to interact with its component.

So, in short, for one-way communication from Commands to Mediators, use notes. If you need to consult a Mediator to find out state information from its component or to carry out a two way conversation (passing something in, getting something back), then allow the Command to collaborate directly with the Mediator.

-=Cliff>
Logged
Pages: [1]
Print