I would like to thank Cliff for giving us such a great framework to work with.  Today we've launched Skimmer (http://www.fallon.com/skimmer) "AIR desktop application designed to streamline, beautify, and enhance the experience of participating in your most frequently used social networking activities".  You can read more about the project technical details here: http://www.blackcj.com/blog/2009/03/24/skimmer/.

I attended Samuel Agesilas presentation on Orchid UI framework at Flashbelt in July 2008.  But since then I've not heard any news on it since then.   I hope that he can resume working on Orchid or open source the code.

JJfutbol could you post the code to cleanup proxies/mediator and registration of subproxies/mediators?

Thanks.

I've a similar question regarding proxy communication to proxy.  I did some searches on this issue on this forum but still can't arrive at a clear conclusion. 

Here's the problem that I've and seen in many posts.  I have a proxy(AggregateProxy) that uses data from many other proxies. So I'm using facade.retrieveProxy to access other proxy in the AggregateProxy.  The AggregateProxy has the responsibility of sorting the collection of data, and some other minor tasks.  The problem that I'm running into is when a search/filter interaction occur, all proxy except AggregateProxy needs to fetch a new set of data with the search/filter condition.  Once the data is fetched(Async) the AggregateProxy needs to know so it can update the master collection and tell the view to update.

I had thought about several solutions but I think there's a better way to go about it.
 
#1.  Handling this with multiple notifications.  On search/filter interaction the view mediator would call the filter/search method on AggregateProxy, which then calls each proxy filter/search method.  The view mediator also listens to all proxy filter/search complete notification. On filter/search complete notification view mediator call AggregateProxy#update() method which updates the master collection data.  Then the AggregateProxy send notification of changes to the collection which mediator pickup and update the view. With this method I feel like the single view mediator has too many responsibilities.  After all the view mediator is really only interested in the master collection data change notification.

#2.  Similar to #1 but using command.  Register a command for search/filter notification in ApplicatinFacade(is there a better place?).  This command would call filter/search method on each proxy in existence and dynamically register command for the search/filter complete notification. The search/filter complete commands call the AggregateProxy#update() method.   Then the AggregateProxy send notification of changes to the collection which mediator pickup and update the view.   

#3.  Create a mediator with null view.  This mediator would handle all notification from the proxy on search/filter complete then have AggregateProxy update it's master collection.  Here I'm pushing all the search/filter complete notification to a new mediator, which make it seems a bit cleaner but Cliff mentioned this is a bad idea since mediator does not go away. 

Are there better solutions to the situation of a proxy that compose of multiple proxy?