[Seaside] VW questions

[Ron Teitelbaum]

Keith,

It sure sounds like the same functionality as the announcement framework.
Check out:

http://decenturl.com/cincomsmalltalk/vassiliannouncementsframework 

http://decenturl.com/lukas-renggli/decouplingseasidecomponents 

Happy Coding!

Ron

> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> bounces at lists.squeakfoundation.org] On Behalf Of Keith Hodges
> Sent: Monday, October 29, 2007 9:05 PM
> To: Seaside - general discussion
> Subject: Re: [Seaside] VW questions
> 
> Hi Ramon,
> 
> >  It's a bad idea because it makes components that aren't reusable,
> > theybecome very tightly bound to their parents.
> >
> 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.
> 
> 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.
> 
> 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.
> 
> When the Alarm card was inserted in the rack it would register for
> cardRemoved: events and raise the appropriate events.
> 
> theRack on: #cardRemoved: send: #cardRemovedAlarm: to: self.
> 
> Subscriptions could also add arguments to a message as it passed through.
> 
> I am begining to think that I might reimplement self routing
> SemanticMessages with a slightly more announcement like flavour for
> Seaside.
> >> Announcements seems limited to me since if using a global
> >> announcer. I cannot see how two similar components on one
> >> page, each trying to announce something to their
> >> parents/containers would be able to.
> >>
> >
> > 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?
> 
> I think that I am struggling to understand announcements and I cant find
> the original articles any longer.
> > You could also just have a sender on the announcement to let the parent
> > decide if the sender was a child, if you prefer a single global
> announcer.
> >
> >
> >> any thoughts would be appreciated.
> >>
> >> Keith
> >>
> >
> > Every time I've gone down the parent path, I've regretted it.  I'll
> stick
> > with announcements, much better approach.
> >
> > Ramon Leon
> > http://onsmalltalk.com
> >
> 
> Thanks very much for your prompt reply
> 
> Keith
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside