[Seaside] Menu component - communicating with root component

[Sebastian Sastre]

> So out use of the #parent instVar should be event or query 
> based, rather 
> than being a direct use of the parents interface. e.g. A child can 
> trigger "I have Changed", and it is up to the parent to respond 
> appropriately. Or a child can seek information 
> #lookupContainingFormId, 
> as long as it can handle the case that a heirarchy of parent which 
> doesnt contain a form may not respond appropriately.
> 
> I am really looking forward to solving this one
> 
> best regards
> 
> Keith
> 

Hi Keith,

	my components have the #parent instVar in their abstract superclass so
they have a proper structure. The only case they are using it is when they have
to anwer if they are children of some other component. They need to look there
because the question is deep (answering true if the component is included as
child of any in its whole parent chain).

	Surprisingly now I've found I've made that #isParentOf: method to
satisfy something I have now deprecated months ago in favor of something simpler
and cleaner. So I really can depracate the isParentOf: also letting me with no
formal need of having the instVar(?). I'll let it there by now :)

	For the announcements part I do use one announcer per component instead
of trying to centralize announcements. Kind of same idea of events and objects.
Every event has its own place to register events. Requires an inst var but it's
simpler and cleaner when components are CG'd.

	I disagree on making exceptions about children querying stuff to
parents. That could easily increase the scoring of the confusivity of concerns
for developers when they have to think of children and parents so encouraging
any trend to mix responsabilities and generate problems.

	The announcements (also events) works in an asyncrhonous style and that
could be a major benefit (depending on your requeriments).

	cheers,

Sebastian