[Seaside] Re: Menu component - communicating with root component

[Holger Kleinsorgen]

Boris Popov schrieb:
> Still, we've build what I consider to be a relatively large and complex
> application and I don't recall ever thinking that it was getting out of
> control. Certainly not to the point of introducing more elements just to
> glue announcers and subscribers together. Let's try a more complex
> example to see if perhaps I am missing something. Say you have a table
> containing rows containing cells and cells announce CellClicked when you
> click on them. If, for some reason, you were interested to know about
> that happening up in the table, how about something like,
>   
the example works, because you have have homogenous components (table 
related). If you insert a different kind of component not related to 
tables somewhere in the hierarchy, it either has to deal with 
"CellClicked" announcements (which is something it shouldnt have to know 
about), or the parent (table component) has to subscribe to 
grandchildren (row/cell components) directly, bypassing over the 
non-table child component.

AFAIK there's no "childComponent 
whenAnnouncingSomethingI'veNotSubscribedToDo: [ : ann | self announce: 
ann copy ]" mechanism do pass unknown announcements.
In contrast, when handling errors with #on:do:, signals not matching the 
specified classes automatically bubble up.

the kind of application I had in mind is highly configurable and 
schema/content-driven, with only little hardcoded logic, so wiring 
together components is tricky with regard to this problem. also, the 
sibling problem had to be solved, so I've carried on with the 
environment object approach. But it's definitely no silver bullet, so 
the using direct subscriptions probably covers most cases.