What should I mediate?

[fragerdaz]

Hi all,

First time user of PureMVC, I've just succeeded in getting Zend_Amf to work with a test Flex project.

Scenario:
I'm building an application in which, datagrid are loaded within tabNavigators.  There are 2-3 tabNavigators, so there can be multiple datagrids showing at the same time (the selection in one will affect the dataProvider for the others).
Example: Selecting a row in datagrid1 (in tabNavigator1) will update the tabNavigator2.  Once tabNavigator2 is updated, the user will select a tab and datagrid2 will be displayed with informaion pertaining to the selected row in datagrid1.

Question:
What should I be creating Proxies and Mediators for exactly?  Should each datagrid have its own Mediator?  Same for the tabNavigators?  Should I only create Mediators for the tabNavigators?  Should I create Proxies based on the PHP service I'll be calling? (ie: one Proxy for each remote service?)

Sorry for the very noobish question, but I can't seem to get my head around what level the PureMVC is supposed to tie to.

Thanks!
-frag

[Joel Hooks]

Hi all,

First time user of PureMVC, I've just succeeded in getting Zend_Amf to work with a test Flex project.

Scenario:
I'm building an application in which, datagrid are loaded within tabNavigators.  There are 2-3 tabNavigators, so there can be multiple datagrids showing at the same time (the selection in one will affect the dataProvider for the others).
Example: Selecting a row in datagrid1 (in tabNavigator1) will update the tabNavigator2.  Once tabNavigator2 is updated, the user will select a tab and datagrid2 will be displayed with informaion pertaining to the selected row in datagrid1.

Question:
What should I be creating Proxies and Mediators for exactly?  Should each datagrid have its own Mediator?  Same for the tabNavigators?  Should I only create Mediators for the tabNavigators?  Should I create Proxies based on the PHP service I'll be calling? (ie: one Proxy for each remote service?)

Sorry for the very noobish question, but I can't seem to get my head around what level the PureMVC is supposed to tie to.

Thanks!
-frag

You don't really need to proxy your remote SERVICE as much as your data model. So, from ZendAMF you are retrieving a list of Widget objects. On the Flex side, you might want a WidgetListProxy that holds an ArrayCollection of all your widgets. In addition, you may want to create individual WidgetProxy objects for each WidgetVO. This is wholly dependent on the level of control you need in your application.

The same is really true for mediators. In the case of a tab navigator, I generally mediate the navigator itself, and then each screen of the navigator, as well as the datagrid that has some control over all the navigators (in your case)

[fragerdaz]

You don't really need to proxy your remote SERVICE as much as your data model. So, from ZendAMF you are retrieving a list of Widget objects. On the Flex side, you might want a WidgetListProxy that holds an ArrayCollection of all your widgets. In addition, you may want to create individual WidgetProxy objects for each WidgetVO.

Thanks for your reply Joel.

So, best to keep all remoteObjects in a single Proxy?

I thought PureMVC recommended coupling each remoteObject with its own Proxy... Not that I see a reason why. Then again, I wouldn't be asking these question

[puremvc]

There are many ways to handle services, but each Service/RemoteObject should have its own Proxy. Why? So that they can be used, tested, and maintained independantly of each other.

The reason we are separating things in OOP is to get at the manageability that comes from clearly defined roles and responsibilities for the actors. Just like in a business, we have managers, developers, secretaries, janitors, etc. They all have clearly defined responsibilities and you know who to go to when the sink is clogged.

A UserProxy that talks to the UserService and holds an ArrayCollection of Users is a manageable scope for a class. It may have methods for updating, deleting, sorting, etc. That's enough for one class. And you can reuse it on its own.

The model is the key place to look for reuse in your RIA client. You may have desktop, web and mobile apps all hitting the same model with different use cases. But they may not all use the entire set of model classes. You may have 8 services, but your mobile may only talk to 2 of your services, while your web app has more turf and use cases, so it talks to 5 and your desktop maintenance app talks to all 8. If all the domain/service logic is in one monolithic class, you've got a problem.

HTH,
-=Cliff>