Inter-Proxies communication. Where to put it?

[binarycrafts]

Problem:
   1. we have a relatively large server application that exposes a REST API. Let's call it Basecamp
   2. we have a structure of Projects, TodoLists and Todos. These are separate tables in the database design. Each TodoList belongs to a Project and each Todo belongs to a Todo list. We use VOs on the client side so we have strong types.
   3. when designing the Proxies, we start with the projects proxy. Now we thing about the Todos and where to keep them.

Question:
   how do we handle the fact that Projects have todoLists in our models design?
   Do we put the todo lists as a property of the Project VO
   or
   Do we keep a separate TodoLists Proxy and use the mediators to connect a project to it's todo lists from the TodoLists Proxy.

The base issue is that the connection between projects and TodoLists is domain logic so it should be handled by the proxy/proxyes (is it domain logic?). Having 2 proxies would require inter proxy communication. How should this syncing occur in a most elegant way? Inside Commands maybe?

ps: While writing this the idea of a project proxy handling a project's todo lists seems not that bad. But then if everything starts from the project, the projectsProxy will soon grow rather large.
Well, I'm grateful for any ideas you guys might have on this. I hope I managed to describe the problem well enough.

cosmin
   

[puremvc]

Hi Cosmin,

It is perfectly fine for one Proxy to create or retrieve another and manipulate it directly in order to share the burdon of managing parts of a part/whole model.

The ProjectVO might be a complex object with many TodoListVOs, and the ProjectProxy might create and register a uniquely named instance of the TodoListProxy and pass it a reference or a clone of the ProxyVO.todoLists member, which would be a list of TodoListVOs.

The TodoListProxy has all the methods for maintaining that list, and a special instance exists for each Project. If it is managing a reference to the data in the other Proxy, that may be all that's needed. But if it's a clone of the data, the ProjectProxy and the TodoListProxy may need to communicate with each other, for instance the ToDoListProxy may need to tell the ProjectProxy that it has added, changed or deleted a TodoListVO.

Also, depending on complexity of your system's use cases, your ProjectProxy may be either a single instance managing all ProjectVOs (or the single one the app allows at a time), or you may need a seprarate ProjectProxy for each ProjectVO.

OR

Your ProjectVO might not contain the list of TodoListVOs, it might be that you have a separate service that retrieves them as needed and you pass it the Project id. This might be good if a project has lots of TodoLists and you don't want to push them all back and forth each time you send a change to the ProjectVO itself. In this scenario, the Proxies don't have such a big dependency on each other really.

-=Cliff>

[binarycrafts]

Hello Cliff and thank you for the reply
Since I skipped the usual "hello first post" let me just say here that I just love all that PureMVC is right now. Great code, great docs, great feedback.

Now regarding the problem at hand:
The API is REST it allows a pretty good separation of projects logic and todos logic for instance. Each todoList has it's own id and u can CRUD it just using that. Well for the C part u need the project id Thinking about this yesterday it's quite clear that the server side already incorporates a great deal of domain logic so the inter proxy comm would mostly be "hey, I changed a bit here and here so u might need to update yourself".
While keeping the array of TodoListVO s as a property of a ProjectVO (project hasMany lists) is natural this might become a problem for more complex data relations. So I think that if the proxies can talk one to the other then I will make each handle one of the data types.
Hmm, right now it's obvious that I'm thinking of the Proxy as a DB table Proxy. Does this seem flawed to anyone?
Well not really a DB table proxy. More a data type proxy. Which should fit the model idea. I think. I won't have a proxy for a table that holds the project types...

Regarding a proxy for each of the project's TodoLists.
How would I manage the creation of many proxies? How does the framework help with the factory thingy. Would this be a job for the ProjectsProxy?

cosmin

[puremvc]

Your probably good just to have a single TodoList Proxy. The idea that there might be many depends on how complicated the data object is and how much logic it needs to manipulate the individual VO. In these cases managing the lis and managing the individual VOs in the lis can make for a fat Proxy. You probably won't need to do that until you find yourelf with one so skip it for now.

when you do need multiple instances of a proxy, just register and retrieve each with a unique id instead of a named constant.

-=Cliff>