Proxy design question

[TripleToe]

How do you handle the design of proxies when you have two classes that might also be combined into a single dataprovider? I've got an application that displays a calendar for pilots to use where they can enter 2 types of events:  FlightEvent and PersonalEvent.  These objects share a common set of properties based on a common interface that allows them to be both be displayed in the UI calendar.   Before the calendar displays them, they have to be placed into a single dataprovider/array.  However, I still need to be able to maintain each type of collection for adds/updates/deletes.   Which of these designs is best?

1.  Make one CombinedEventsProxy that maintains two internal arrays, one named flightEventsArray and one nameed personalEventsArray.   This proxy would also be responsible for providing the combined array as a property called combinedEventsArray which aggregates the two arrays into one.  I would also have the methods on this proxy to add/update/delete items of each time within their specific arrays and then update the CombinedEventsProxy accordingly.

2.  Make a FlightEventsProxy and a CalendarEventsProxy, each of which is responsible for their own types of events.  Then create a third CombinedEventsProxy that makes calls to FlightEventsProxy/CalendarEventsProxy in order to build the aggregated list of events that it will provide.  This approach seems a little better, but I'm not sure how to handle all the inter-proxy communication because I think I would need to have the CalendarEventsProxy call FlightEventsProxy/CalendarEventsProxy to initially build the combined list, but I would also need the FlightEventsProxy/CalendarEventsProxy to call the CombinedEventsProxy back to let it know that its contents need to be updated.  This coupling seems a little strong to me.

Any suggestions on how to handle this so I can get a combined view of all the events and still issues commands to CRUD each individual type of event?

Thanks

[puremvc]

#2.

Within the model, its not unreasonable to have proxies interact. The biggest issue with couplings is between Model and View. That's where the spaghetti really happens.

Consider your 'combiner' proxy to be similar to a 'view' in a database, that pulls together data from different tables to form a unique 'view' on the data. Its defined in the same db, but isn't an actual table. Its better than executing a query eace time to get that data though.

-=Cliff> 

[TripleToe]

Thanks for the reply Cliff.  I knew I could count on you 

Regarding approach #2, should I focus on making sure the linkage between the CombinedEventsProxy and the FlightEventsProxy/CalendarEventProxy goes in just one direction?  To clarify, should I have a reference to the CombinedEventsProxy inside of the FlightEventsProxy/CalendarEventProxy objects so they can call an update() method on the CombinedEventsProxy when their own contents are updated?   Or should I got the other direction, having the CombinedEventsProxy contain reference to FlightEventsProxy/CalendarEventProxy and just have it pull and combine their data arrays ondemand (when a call is made to CombinedEventsProxy.getCombinedEvents())?  Or are these both wrong?

[puremvc]

One way. CombinedEventsProxy knows about the others but they do not know about it.

Use a CombinedEventsProxy.getCombinedEvents() method, and when your other Proxies are updated, send a Notification that any Mediators needing this combined info will be interested in. They will then call CombinedEventsProxy.getCombinedEvents and update their view components.

-=Cliff>

[TripleToe]

Makes perfect sense now! Thanks   

[lingie]

Why is #2 the better option?  Is there a justification for that choice in terms of the PureMVC Implementation Idioms & Best Practices doc?  I like #2 (it's aesthetically pleasing to me), however, since I'm trying to learn PureMVC, I'm wondering if there is more to this decision...?

Anna

[puremvc]

Because #1 would lead to a monolithic CombinedEventsProxy.

Not only should the proxy hold the array of data objects, but it should expose methods for manipulating those objects in the arrays, providing create,update and delete methods, 'get by name', 'get by flight number' etc.

-=Cliff>

[lingie]

OK - makes sense - thanks!