SearchPanel Updating

[sehcheese]

This one has proven for me to be quite a head-scratcher. After trying a number of approaches, I have not found a solution that I would deem truly optimal. The SearchPanel works as it is, but the architecture may be confusing and could perhaps be simplified if it were implemented in a better way. Read on to see what I mean.

Currently, there are some tabs that have a SearchPanel and some that do not. Tabs that have their own SearchPanel have their own instance of it, and they must - these components are not reusable in that manner. The trouble comes in keeping these separate instances of SearchPanels in sync. When a different client is selected in one, we want that same client to be selected in all of them, and the information in each tab to be updated appropriately.

It seems to me the best way to approach this was to have the SearchPanel class notify the FoodPantryManager object of a change in the selected client. Then FoodPantryManager, which already knows about all the tabs, can propagate the change appropriately. This works wonderfully for updating the information in each tab, but not the search panels which were passive in the update. The search panels the user did not interact with should show the proper client selected. To do this requires programmatically changing the selected client, which will fire an event that the selected client has changed and again propagate the change to the other tabs via the dispatch of FoodPantryManager. So changing the selected client in one tab fires as many events and updates as changing the client once in every tab. Because there is no practical difference between the user changing the selected client in the search panel and the program doing it, we cannot stop all these events from firing. If we could use just one SearchPanel everywhere that would solve our problem, but we can't. If we could distinguish between a user changing the list and the program doing it, we could solve this, but so far I have not discovered a good way to do this.

With n^2 events occuring, we ought to do something to nip the unnecessary ones in the bud. And indeed, we currently kill these with a check in each of the panels implementing IUpdateOnSearch:

// c is the client to update, if it's the same as the active client, we're current
if (activeClient == c) return;

This may require a substantial architectural change. If that is necessary and worth it, we can do it.

Thanks,
sehcheese