Best practices on proxy/mediator relationShip

[crilbit]

Hello,

After a first PureMVC project implementation i found some points where i'm not pretty sure :

- Reference of the proxy in the mediator

I try for all the project to avoid that kind of link to prefer using the following chain
mediator notification/command/proxy/delegate/proxy notification....
But I got a single command that only retrieve  proxy to call a method of it API
A lot of code when i can do it directly in the mediator.
Is there a kind of consencus for when we can use the proxy directly in the mediator or not.

- Multi instance of proxy and mediator ?

This is what i m' the most confuse with puremvc. When i have multi instance of mxml component in my application. For example a list of user that can appear in several view. So i have an instance of mediator for each view. But the list of user can be different (for exemple a list of authorized users and a list of banned users). So I imagine that I also have to manage 2 proxy and the mediator will only be interresting in there proxy notification. I understand that mediator can send notification that use type argument as discrimination.

But  some time the mediators are register in other mediator so the discriminator need to be passed through several mediator. And for a simple view it is ok but I wonder if it is not too laborious to passe the type from mediator to command to proxy (with asynchronous request) and then back to mediator in big application.
Is there another way to do it ?

Thank you for any help or suggestion

Cyril Balit

[puremvc]

is there a kind of consencus for when we can use the proxy directly in the mediator or not. s there a kind of consencus for when we can use the proxy directly in the mediator or not.

Yes, you can. The view has no other purpose in life but to expose the data model to the user and allow them to view, navigate and update it. Therefore it is a given that the View tier will have relationships with the Model tier whereby it has implicit knowledge of its actors. The Mediator may certainly have references to the Proxies needed to feed its view component. Using circuitous paths such as notification/command/proxy/delegate/notification/mediator to get a mediator the requested data rarely gains you anything valuable; instead it adds complexity that is difficult to follow later, particularly if you didn't write it.

Multi instance of proxy and mediator ?

I have difficulty actually understanding your elaboration, but from the question quoted above, I will venture you might be wondering how to have multiple instances of a given Mediator or Proxy. You do that by registering the actor with a unique name, not just the NAME constant, but usually the value of the constant with an ID appended to it that is tied to the data object or view component it tends.

HTH,
-=Cliff>

[crilbit]

Thank you for your response.

I 'll try to explain a little more my second question.
For example with the following structure :
componentA/mediatorA/proxyA
componentB/mediatorB/proxyB with B include in A
mediator A need to listen to mediator B notification

And now i use multi instances of A and B in my application. I understand the use of a unique id to be pass in the notification and this what i have done in my application. 
But you need  to share you id with 'child' mediator so that  A handle only its 'B' notifications.
So you have an id that is passed in all notifications (concerning those components)

In fact it is not really a question. I understand the way it should be implement. I just wonder if it is no going to increase complexity with a large component hierarchiy

Cyril

[puremvc]

Components live in a hierarchy, but Mediators don't. 'Child mediators' aren't really a sensible notion.

-=Cliff>