[Seaside] VW questions

Ramon Leon ramon.leon at allresnet.com
Tue Oct 30 02:18:01 UTC 2007


> I saw that on a blog somewhere, but I am not sure I buy it. 
> Surely they only become bound to their parents if you use the 
> relationship over rigidly.

Sending direct message to parents is what causes the problem.  If you're
just crawling the hierarchy looking for a handler, I can see how that is
less rigid.

> Consider the situation anthropomorphically... If I am 
> presently in a car, I can see and know that I am in a car. If 
> I choose to shout then all of the car can hear me. If I am in 
> a bus, I can see I am in a bus, and again if I shout in the 
> bus the bus driver can hear me. However I am not chained to 
> the bus and can take the train if I want to.

If a component can see and know it's parent (which I've done myself), the
temptation t send message to that parent are overwhelming and soon, you
can't use any other parent.  The component becomes glued to its context.

> When modelling physical telecomunications equipment I always 
> implemented parent-child relationships, and certainly never 
> regretted it. Basically I used the #parent for routing 
> semantic messages.
> When a card was removed from the rack it would instanciate a
> SemanticMessage-cardRemoved: aCard (based upon the ideas of 
> SemanticMessages in SmalltalkAgents) This message would move 
> up the heirarchy looking for an object to either a) directly 
> handle the message
> #cardRemoved: aCard or if the item had any subscriptions 
> registered such that on: selector send: message to: subscriber.

This requires too much discipline for me, I'd rather shout "I'm removed" and
let the context handle it appropriately, which may mean not at all.  If
interested people have already subscribed... I don't need to climb anything,
I just shout "I'm removed".

> > You don't have to use a global announcer, every component can have 
> > it's own announcer and you can have parents subscribe to 
> events their 
> > children throw that they're interested in, this keeps the children 
> > loosely coupled and reusable.
> >   
> And this was what led me to wondering how on earth this works at all.
> 
> How do the children find the parents announcer, if they do 
> not know whom their parent is?

You've got it backwards, children just announce using their own announcer.
The parent *knows* it's children and registered as a listener for any
announcements they make when it created them.  The child has no need to know
the parent.  A wheel doesn't know what car it's on, it works on any car.

> Thanks very much for your prompt reply
> 
> Keith

No problem, I've struggled with the parent thing myself, even added parents
to my own components for a while, but I just find it too inflexible when I
want to use the component somewhere else.  Parents registering to child
events is just so much more loosely coupled and easy to assemble than
children knowing their parents in my experience.

Ramon Leon
http://onsmalltalk.com



More information about the seaside mailing list