Module to Module Communication

Topics: Prism v2 - Silverlight 3
Nov 5, 2009 at 6:57 PM


I am fairly new to prism/composite applications.  To test my understanding of the concepts, I am building a sample application and I have run into a scenario that I would very much like to get feedback on.

My shell exposes two regions that are populated by modules exposing a treeview user control and a listview user control (respectively).  These controls display different types of data.  I would like to implement some functionality that would allow the content displayed in these controls to be filtered based on text input into a text box (similar to iTunes search).

Visually, I am picturing the two "filter boxes" being present, one directly below the treeview and another directly below the listview. 

If I were to implement a module to host the FilterBox and create two new regions in the shell to host two instances of FilterBox, how would I coordinate communication to the treeview and listview modules??  I have considered using the Event Aggregator to allow the FilterBox to publish an event when the value in the Filter Box changes (FilterCriteriaChangedEvent).  The treeview and listview controls would then subscribe to this event and do the filtering.  However, this presents a problem since typing in either filterbox would cause both controls to be filtered.

This leads me to believe that I wouldn't want to define the filter box regions directly in the shell.... 

Instead of defining the FilterBox in its own module, I would place its components in my Infrastructure project and then explicitly instantiate each filter box in a scoped region in each of the controls (treeview and listview).  Then I could use the region context to communicate the changes, but this seems awkward.  Does the event aggregator also have a concept of scope??

Any feedback would be greatly appreciated!  Thanks in advance!

Nov 9, 2009 at 7:43 AM

Since the filterbox is so tightly bound to the list it's supposed to filter I would have put that in the same View & ViewModel as your list.
And then you won't need to use the EventAggregator, but can rely on databinding.

Any specific reason you wanted to have the filteboxes directly in the shell instead (or in it's own module) ? If you wanted to do that I guess you would simply pass on some object/value as a parameter when you fire your aggregated event, and have your different listboxes/treeviews whatever to filter only if that parameter matches its own.