You have three choices:
1. Propagate up the controller hierarchy.
This is the easiest and best option when the objects are actually in a hierarchy or tree on the model side, because then each object's controller has an explicit reference to the parent object's controller.
2. Propagate up the route hierarchy
This is the best option when the view hierarchy does not necessarily correspond to a tree structure in the models, but is semantic. If you think the semantic arrangement of the related objects is prone to change in the future, this a better option. However, you are still assuming that there IS a hierarchy
3. Let the first handler be the topmost route that "knows" how the objects are related,
and that handler sends events to the necessary controllers.
This option is best when the relationship between the objects in a particular set of views is semantic and not necessarily hierarchical and you think the routes/views might move around during the development of the app. The best example of such situations are "negative" events -- for example, deselect
You can always mix these strategies. I've found that refactoring is easier if events tend to go up to a route and back down to necessary controllers rather than having a lot of needs
in my controllers.