Hi Thierry,

I didn't realize that you had a third party establishing the registration
for the child morph.   I looked at your code - nicely done, btw - and saw in
#expandOrCollapse: where the HierarchicalList is triggering the event.
Which objects are interested in subscribing to this event?  The reason I ask
is that the item morph is already notified through #toggleExpandedState and
is an Expandable morph.  Could it be the container that has embedded the
hierarchy list morph?

Here's my philosophy regarding events in the UI.  When objects are in a
parent -> child relationship  (morph -> model, or container morph ->
contained morph), and the child changes, the child should trigger events
that the parent may have interest in.  This way the child can ignore the
multiplicity of parents.  However, when the parent changes, the parent
should direct the child with message sends, rather than trigger an event for
the child to respond to.  The only reason a parent should trigger an event,
is if its container would be interested in responding.   I also think events
are effective when dealing with siblings, but that is usually within the
context of a parent.

So perhaps it should be the itemMorph that triggers the event and the parent
that has registered an action for this event.  The parent may then retrigger
an event for its parents.  If that is the case, the the event could actually
be triggered in #toggleExpandedState, and the HierarchyListMorph's action
could be to #adjustSubmorphPositions and retrigger an #itemExpanded event.
YMMV

when adding listed items:
    aMorph when: #expanded send: #itemExpanding: to: self with: aMorph.
    aMorph when: #collapsed send: #itemCollapsing: to: self with: aMorph.


SimpleHierarchicalListMorph>>expandOrCollapse: aMorph
 aMorph toggleExpandedState.

SimpleHierarchicalListMorph>>itemExpanding: aMorph
 self adjustSubmorphPositions.
 self
    triggerEvent: #itemExpanded
    with: aMorph.

SimpleHierarchicalListMorph>>itemCollapsing: aMorph
 self adjustSubmorphPositions.
 self
    triggerEvent: #itemCollapsed
    with: aMorph.

ExpandableMorph>>toggleExpandedState
  "expansion stuff.."
  self isExpanded
    ifTrue: [self triggerEvent: #expanded]
    ifFalse: [self triggerEvent: #collapsed].




cheers,
rob

----- Original Message -----
From: <thierry_Reignier at hotmail.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, December 10, 2002 6:52 AM
Subject: Re: [Q]: Update: mechanism


> Hi,
>
> > we probably do not want to install exception handlers in these
> > methods, since that can slow things down (a little).  Basically your
> > subscriber is violating the contract, by asking for a msg to be sent
> > but not
> I will make it easier and make the event registration the
> responsability of the subscriber. Non registered event
> are then caught by the normal behavior of ifNotHandled...
>
> Forget my suggestions then
>
> Thanks.
>
>
>
>