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 for mouseEvents in Mediator  (Read 7587 times)
bmonke
Newbie
*
Posts: 3


View Profile Email
« on: April 29, 2011, 04:29:33 »

Hi, I was wondering what is the preferred way of handling mouseEvents in regard to the independence of the view component and its mediator?

For instance, I have a button which I have to have a listener for in the mediator that tracks that it has been clicked and then sent to a command in the framework. So it would make sense that I add a listener for it from the mediator. But that same button has an effect on the view component itself at the same time (toggling visibility of other elements in the view component). So I came up with the following possibilities:

1) Add only the listener in the mediator, and handle the sendNotification and view component's elements through the shortcut viewComponent getter method

2) Have an independent mouseListener in the mediator that handles only what needs to be communicated with the rest of the framework AND have an independent listener in the view component to handle its own visual elements

3) Have only one mouseEvent listener in the view component, which then dispatches an event listener (a text string) up to the mediator once it is clicked.

1 offers less code, 2 seems to be more in line with my limited understanding of the appropriate roles of mediators, and 3 seems to just be an alternate version of 2. It seems somehow wasteful to have 2 mouseEvent listeners on the same object, however.

Any ideas as to what is the best practice?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: May 02, 2011, 08:10:58 »

Don't put the listener in the mediator. That's really breaking the encapsulation of the view component. Instead put the listener in the view component itself and dispatch an event which the mediator listens for.

There is good reason for doing it this way. Encapsulation leads to better maintainability.

Lets say the user is to select an item in the data grid and click the button. You put the listener on the button in the mediator. Then later a requirement comes that you should also be able to double-click the item in the grid with the same effect as selecting it and clicking the button. Now you have to refactor not only the component but also the Mediator. However if you'd been listening for an event dispatched from the component instead of listening to the button, then you'd only need to refactor the view component to dispatch the same event when double-clicking the grid.

-=Cliff>
Logged
bmonke
Newbie
*
Posts: 3


View Profile Email
« Reply #2 on: May 07, 2011, 11:49:01 »

This makes a lot more sense... also produces the least code (not having to getChildAt through for loops to add listeners to all the button on a VC). Thanks!
Logged
Pages: [1]
Print