My problem is with JavaScript in the browser but I guess it could apply to any event-driven environment.
I have coded up a widget in my app. The widget allows a user to select an item using 3 different sub-widgets (table, map & gallery). The sub-widgets display the same items and a selection can be made from whichever sub-widget the user prefers to use. Whenever a selection is made by the user or set in code a "selection-changed" event is fired by the sub-widget. The main widget listens for these "selection-changed" events.
This worked fine until I started getting further on with the project and realized that I needed to adjust the selection in the other 2 widgets when the selection changes (If the user selects an item on the map, it should highlight that same item in the table and gallery). The problem is that when I set the selection in the other 2 sub-widgets they in-turn fire the "selection-changed" event and that ends up getting pretty recursive. This also happens when I need to clear the selection in all of the sub-widgets (I get 3 "selection-changed" events with the same empty data). This leads to several redundant calls being made for external resources and gives me the feeling it will lead to further problems in future.
So my question is am I doing events right? The answer is obviously 'no' because I've got myself in to a pickle so early on but I wonder how other people use events without getting in to these problems - what kind of architecture would be better in this situation?
Maybe I could have a way of setting and clearing selections in the sub-widgets that doesn't go on to fire the event but this feels like a hack and may end up conflicting with the framework I'm using to handle my views/models.
selection changed by user
andselection changed by program
.