PureMVC Architects Lounge

Announcements and General Discussion => General Discussion => Topic started by: valuetime on July 27, 2009, 06:58:41

Title: Using more commands.
Post by: valuetime on July 27, 2009, 06:58:41
We're having a bit of a in-office debate on PureMVC best practice, and I wanted to get an opinion on the way I've historically been using PureMVC. I'm using the login form example from the best practice document (http://puremvc.org/component/option,com_wrapper/Itemid,174/).

I prefer to map the LOGIN_SUCCESS and LOGIN_FAILED notifications to their own SimpleCommands (eg: LoginSuccessCommand and LoginFailedCommand). These “extra” commands would call retrieve and call public methods on the LoginMediator (eg: LoginMediator.onLoginSuccess and LoginMediator.onLoginFailed) as opposed to using the LoginMediator.handleNotification switch statement.

I like this for a few reasons:

In large applications, it centralises the code into “actions” (or verbs, as I like to think of them). If I want to change the way that the application reacts to the “successful login” action, I can simply find it in one place (i.e.: LoginSuccessCommand), and have total control over which order things happen in. In the best practice example, if multiple mediators needed to react to the same notification, I either need to remember where these are or search for all matches for a notification to edit them, and I can't control the order they happen in.

Additionally, I can easily update a Proxy and a Mediator at the same time in a predetermined order. Say I needed to check or update a data object containing the application’s state (AppStateVO via AppStateProxy, for example). My LoginSuccessCommand could then call public methods or getters on the AppStateProxy before it updated the LoginMediator. If things get really complex, I would use a MacroCommand, but this is the general way I’ve been approaching this problem.

What are the issues (if any) with this from a best practice standpoint? I now do this so often that most of my applications do not utilise Mediator.handleNotification at all. I opt instead for three or four line Command.execute methods that simply retrieve Mediators and call public methods on them, exactly the same way that is recommended for using a Proxy.

Any thoughts from a best practice standpoint would be much appreciated.


Title: Re: Using more commands.
Post by: puremvc on July 31, 2009, 03:57:15
From a fanatically purist perspective, only the View should receive notifications from the Model.

The classic MVC diagram1 describes the Model notifying the View and the View updating the Model. The View may notify the Controller and in turn the Controller may then update the View or the Model.

However, in practice it is possible for the Controller to receive notifications from the Model, and there are no best-practice reasons why you shouldn't do things the way you describe.

I find that the architecture of the rich client is mostly about tossing a ball back and forth between the Model and View, and the Controller is useful for high-level orchestration when needed. I opt for smart view components and smart value objects and rarely need Commands.

1 http://puremvc.tv/#P100/T110


Title: Re: Using more commands.
Post by: hesten on August 10, 2009, 01:06:30
I am curious because my understanding of MVC was that the view simply gathers the user input (or presents model data for the user) and have the controller actually process the user input?

What I've translated that into in PureMVC terms is by example;

A user requests data by a button input (the view component). The mediator sends a notification which is registred with a command that processes the request (even if it is just a proxy.getRemoteData(someID) ), and has the model (proxy) update the data, parse it, and send a notification which is listened for by the mediator.

Is this an unneccesarily complicated procedure? Are you arguing in favor of removing the command and having the mediator call proxy.getRemoteData(someID) itself?

From a fanatically purist perspective, only the View should receive notifications from the Model.

What would be the purists argument for such practice?


Title: Re: Using more commands.
Post by: puremvc on August 10, 2009, 03:02:56
The view, from the purist perspective may either notify the controller tier or update the model. The controller may also update the model.  Since the view's job in life is to represent the model, it is understandable that it will have a somewhat cozy knowledge of the model tier. It is the other direction of coupling we are most concerned with; the model should have no dependency on the view. The View and Controller work hand in hand to execute the unique use cases of the application against the model (which might be reused in other apps, and must therefore be self-contained and without dependence on view or controller).

Hope this helps,