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

[Ramon Leon]

> I assume then that bodyB, when added, said to its annnouncer, 
> if any ReloadBody events come up I am able to respond. I 
> assume this, because in my system the parents dont know any 
> details about their chidren, a pier page is merely a 
> container and can have anything put into it to any level of depth.
> 
> So... where is this announcer, how does bodyB obtain its 
> announcer? If there is one global announcer, then what routes 
> a ReloadBody to the Correct BodyA or B.

OK, consider this, in Seaside, all components answer #children, so all
parents have access to their children.  The ChangeBody announcement could be
fired like this...

self session announce: (ChangeBody sender: self with: [:body | body call:
BlaBla new])

Now, both parent components catch the event, check to make sure the #sender
is one of their children or grandchildren with a quick recursive check on
#children, before deciding to process the announcement.  This way you scope
the ChangeBody to the correct parent.

> 
> So menuItemB, performs "self announce: (anAnnouncement)" on 
> an announcer.
> 
> ok... where is this announcer? How does it know about it?

Put it on the session and then every component has access to a single global
announcer.

> But all we are doing is here is replacing, child knows his 
> parent, with child knows his announcer, or in the case above 
> child knows his global-announcer.  I think that first is more 
> useful than the last two, because last two give neither the 
> child nor the announcer any spatial information at all.

Yes and no, yes a global announcer, but you're wrong about the spatial
information because all components know their children, you can always
iterate and check this.

> Ok so thats all connected and would work...
> 
> but what if there were two menus, and we want the menu to 
> flash when an item is selected.
> For this, each Menu will need its own Announcer, and each 
> menuItem is given the MenuAnnouncer when it is added to the Menu...

Not necessarily.

> Hang on there, each MenuItem ends up having the announcer of 
> ifs Parent... why not just have a reference to its parent, 
> and ask its parent for an announcer.
> 
> thanks in advance for any help, I am still really struggling 
> to understand how announcements are supposed to work in a 
> heirarchical system of nested components, without any spatial 
> relationship information at all.
> 
> Keith

But there is spatial information, you're just not using it because you're
stuck on wanting the hardcoded parent path because it seems easier to you.
It's not easier, it's messy and results in fragile hierarchies of components
that become really hard to reuse when you change the structure.
Announcements allow you to loosely couple them so changing the structure
doesn't break things.  As a solution to message sending, #parent is fragile,
#includesChildRecursively: is not.  Just think of the announcer as a global
message queue where all objects can exchange messages as peers rather than
parents and children.  A parent can easily ignore messages that aren't from
it's family because it can check the sender against it's known family
(#children) whenever it likes.

Ramon Leon
http://onsmalltalk.com