Why would you want to register a Proxy through a command?

[Helmut Granda]

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?

[puremvc]

The Facade registers its initial commands to when it is created. This gives us the ability to actually do something when getInstance() is initially called.

Then we prepare the Model by registering the initial Proxies. We do this by Command because the previous step affords it.

Then we prepare the View by registering our initial Mediators. When we register our Mediators, they often retrieve references to their frequently accessed Proxies. Multiple Mediators may retrieve references to the same Proxies. We wouldn't want to do those Proxy registrations in a particular Mediator, as that would force us to order the registration of individual Mediators and getting them out of order would cause a failure whose reason wouldn't be obvious. Much better that the Proxies are already there whilst preparing the View.

Beyond that, at runtime, if a Mediator needs a Proxy registered that only it will talk to, there's no real prohibition on a Mediator registering it, but that activity really does fall somewhat outside the declared responsibilities of the Mediator: mediation of communications between the app and the view component. Making sure that all the actors are registered so that they can communicate is more of the stated responsibilities of the Command: coordinating system-wide activities.

-=Cliff>

[jpwrunyan]

I was under the impression that ALL proxies would be registered in a start-up command, but that's not necessary, is it?

It sounds like if I want a Proxy only when a certain Mediator's view state demands it, I should register the Proxy in the same Command that changes the Mediator's view state.

I've actually got this very same problem.  We don't want to register (and set) proxy data at start-up for every screen in our application because, depending on the user, some screens may not be displayed over the course of one session.  So getting that data in the start up Command is a drag on start-up time and memory.  Better to wait to get it until it needs to be shown.  This is the same principle as Flex deferred instantiation (with the same benefits/drawbacks).

[puremvc]

Correct. You can register Proxies just when you need them (and feel free to remove them afterward). That's efficient, but it takes more code to ensure that the register and remove are done at the right time.
If you want to do this, then you may want to implement application-wide states with the StateMachine Utility and have it do this stuff when states change.

But unless you have a really huge number of Proxies, the hit to instantiate and register the Proxy classes at startup isn't really going to be bad. But you don't necessarily want to have those Proxies run off and request their data right away. You can always register the Proxy but defer any service instantiation and data loading until a method on the Proxy called that requires it.  This is certainly the easiest and least complex approach.

-=Cliff>