Why would I want to register a Proxy through a command rather than registering it directly through a Mediator?

I was wondering why would you do that, specially during instantiation but the more I was reading about the subject I discovered that the benefit of doing this through a command is that then I have the ability to call the proxy methods through the Command when necessary rather than being tied up with a specific Mediator.

From the Docs:

Preparing the Model is usually a simple matter of creating and
registering all the Proxies the system will need at startup.
 
The ModelPrepCommand above is a SimpleCommand that prepares
the Model for use. It is the first of the previous MacroCommand’s
sub-commands, and so is executed first. 
 
Via the concrete Façade, it creates and registers the various Proxy
classes that the system will use at startup. Note that the Command
does not do any manipulation or initialization of the Model data. The
Proxy is responsible for any data retrieval, creation or initialization
necessary to prepare its Data Object for use by the system.

Could some one confirm my thoughts?

I have a navigation view which then creates sub views (or buttons):

component
/navView
/buttonView

Should the events bubble from the buttonView -> navView-> navViewMediator or is it best to let each buttonView talk directly to the Mediator?

The buttonView pretty much creates a complex view that is several lines of code and that is why I decided to create a viewClass of its own, but nothing else is going on in there other than the complexity and dispatching events (rollover/rollout/click).

Thanks everyone for your comments and for the confirmation that still in PureMVC you can skin a cat in many ways.

Ok, so now I have it all working nicely and is getting better by the minute, but I just realized that I have one DataCommand that is registered with Multiple Proxies.

:

registerCommand ( SettingsProxy.GET_DATA, DataCommand ) ;
registerCommand ( SettingsProxy.DATA_READY, DataCommand ) ;
registerCommand ( BrowserProxy.GET_DATA, DataCommand ) ;
registerCommand ( BrowserProxy.DATA_READY, DataCommand ) ;
The only draw back that I see on this is that my DataCommand can become quite large when it has to manipulate large blocks of information, in which case I was thinking of breaking it into smaller commands.

:

registerCommand ( SettingsProxy.GET_DATA, SettingsCommand ) ;
registerCommand ( SettingsProxy.DATA_READY, SettingsCommand ) ;
registerCommand ( BrowserProxy.GET_DATA, BrowsserCommand ) ;
registerCommand ( BrowserProxy.DATA_READY, BrowserCommand ) ;
I guess with a small application the first option is ok but as the application becomes larger then the latter would be preferred.

Thoughts?

Thank you for your comments Isragaytan. ( o como diriamos en otros lados. Muchas gracias! ).

//in ApplicationMediator

      override public function handleNotification(notification:INotification):void 
        { 
            var name:String = notification.getName(); 
            var body:Object = notification.getBody(); 

            switch ( name ) 
            { 
                case BrowserProxy.DATA_READY:
               var setingsProxy : SettingsProxy = facade.retrieveProxy ( SettingsProxy.NAME ) as SettingsProxy ;
               setingsProxy.settingsDataGet();
                break; 
      
            } 
        }

The ApplicationMediator is the only one who cares if the Browser Settings have been set. Once that is completed then we need to make a new call to SettingsProxy to get information from a XML.

Again this works perfectly but I am wondering about this in regards to best practice.

search and found: http://forums.puremvc.org/index.php?topic=1419.0

I have a piece of code that could be used by different applications. It is used by a proxy twice for the life of my current app and I could just add it to the proxy but say I want to move that piece of code as an utility. Is there any specific utils folder within the framework? I couldn't find anything within the docs for best practices.

I would assume this is more left up to us than something specific to the framework.

I think I understand. So in this case the ApplicationMediator and onRegister seem to be the two pieces of the puzzle that were missing.

I wish there was a sample application for every single instance and every single project I am working on so that I could just "copy and paste" and be done with it. kidding kiddding...

I just went ahead and used the Proxy itself to start fetching the information and it works but this seems really hacky to me.
            
on the StartupCommand
            

:

facade.registerProxy ( new DataProxy ( ) ) ;            
in the proxy
            

:

public function DataProxy ( ) {
        super ( NAME , new DataVO() ) ;
//hack?
getDataFromBrowser(); // it works but shouldn't i be calling this from somewhere else?
}            }

Another thing that throws me off is in my case. Who initiates the Proxy? Everyone else is waiting for the proxy to be completed but who tells the Proxy to go and fetch the data on the browser?
      

I have a piece of data that needs to be gathered from the browser at the begining of the application. The Data will be used by the application and it is imperative that is available in order for the app to work.
      
Most examples that I have seen are used where Proxys send informations during the life of the app.
      
What I am doing right now is to register the Proxy during the StartupCommand, so do I just register the rest of the actors and have them listen for the event that allows the application to run?
      
I am sure I making this more complicated than it should be.

I have taken the time to look at StateMachine but the more I studied it the more confused I was getting so I am back to square one, where I can understand all the basics properly and then add those new items.

It does makes total sense and it is the core of this kind of development.

It is so tempting to do the wrong thing with so much power.

from the docs:

Some good rules of thumb are:
 
o If a number of other Mediators must be involved in
the overall response to an Event, then update a
common Proxy or send a Notification, which is
responded to by interested Mediators, all of whom
respond appropriately. 
 
o If a great amount of coordinated interaction with
other Mediators is required, a good practice is to use
a Command to encode the steps in one place.

From the documentation:

When they are registered with the View, Mediators are interrogated
as to their Notification interests by having their listNotifications
method called, and they must return an array of Notification names
they are interested in. 
 
Later, when a Notification by the same name is sent by any actor in
the system, interested Mediators will be notified by having their
handleNotification method called and being passed a reference to
the Notification.

Here is my question. I have views within my views like this:

top level view -
---mediator
-------low level view

now the "low level view" is instatiated by the mediator and it is basically a button. I am able to send a notification from the "low level view" that the mediator recognizes and is able to process correctly but I am 100% percent certain this is not the way to go. Having access to the facade from any place makes it easier to send notifications from any where but is that beneficial?