PureMVC Architects Lounge

Announcements and General Discussion => General Discussion => Topic started by: Vishwas on November 25, 2011, 12:29:12

Title: Adding Listener to componentDataProxy ?
Post by: Vishwas on November 25, 2011, 12:29:12
I wanna listen to some event dispatched by componentDataProxy.
However, i note that i can't do  since dataProxy doesnot have addEventListener function. How should i achieve it ?


Title: Re: Adding Listener to componentDataProxy ?
Post by: puremvc on November 26, 2011, 01:55:47
You send Notification from Proxies, not Events.


Title: Re: Adding Listener to componentDataProxy ?
Post by: Vishwas on December 03, 2011, 12:44:37

I am actually getting confused with the role of proxy here. Proxy is so much visible in all the mediators, that it can be accessed from all of them. Then why would anyone go through Commands in between, as a lazy programmer would always like to access proxy rathar then planning it to be accessed via Commands.


Title: Re: Adding Listener to componentDataProxy ?
Post by: puremvc on December 03, 2011, 01:42:26
In the classic MVC diagram,[1]; The View is allowed to update the Model, and the Model may notify the View. So, you do not have to go through Commands to access Proxies. But you also don't want to do a bunch of logic in Mediators either.

If you get an event from your view component saying, 'submit this data', you can take that data and pass it to a Proxy method. No problem. It's a simple hand-off, and there is no rule saying you can't do this.

Some people like to route all handling of the Model through the Controller just because it gives them a comfort to know that they are locating it all in one place. They don't mind creating the extra commands, because it just feels more orderly. Nothing wrong with that. This approach is more commonly known as Three-tiered Design[2], but often confused with MVC.

And sometimes there are good reasons beyond warm fuzzies, such as putting client-side validation in one place, and relieving the Mediator of any undue responsibility for the logic involved.

Maybe you have different view components that trigger the same Proxy interaction. A keyboard shortcut, a context menu item, and a button, all communicating with different mediators, but triggering the exact same operation to happen. By putting it in a command, if the Proxy ever changes, you know that you only have the one place to modify; the Command.

Or perhaps you have an application that exhibits different behavior for online and offline operation. You don't want to saddle your Mediator with the responsibility of executing conditional logic based upon
evaluation of the application's connection state, that's business logic, which goes in a Command. Mediators are for mediation, not cogitation.

As a best practice, going through Commands more loosely decouples your View from your Model, allowing them both to vary. From a strict separation standpoint this is good. It leads to more Commands, but the benefits are there in legacy maintenance.

If your Proxies never know your Mediators and you scope your Mediators to just communicating the View Component's intent to a Command, and being interested in the Notifications that are important to the care and feeding of the View Component, then you have achieved maximum Model and View separation and thus maximum variability of both.

All that said, there is a certain value to the old saying "don't put the cart before the horse". You can always save yourself the effort of creating and registering a new Command to make a single Proxy method call and just wait until you need that variability, then refactor toward more appropriate separation. You can always move a Proxy call out of a Mediator into a Command, when you find you need to reuse the code or decouple the actors. Developers who allow their Mediators to communicate with Proxies need not feel like they're being slack, they're simply using MVC as opposed to strict Three-tiered Design.


[1]MVC Diagram

[2]Three-tiered Design (Note that the tier diagram is stacked, not triangular like MVC, because everything goes through the logic (i.e. controller) tier in the middle)