[Seaside] Re: Menu component - communicating with root component
siguctua at gmail.com
Mon Apr 21 18:22:44 UTC 2008
2008/4/21 Sebastian Sastre <ssastre at seaswork.com>:
> > So what about drivers that are parked around the corner, they
> > cant even
> > see the light physically, yet they get the event!
> Well.. in which architecture? In my proposal they don't receive the event
> because the semaphore announces its light changes only to its own subscribers.
> The subscribers at that time will be only those drivers with that semaphore in
> sight. Same for the rest of the drivers and semaphores.
> > Does this then mean that every driver has to check every
> > object in the
> > entire world, for line of sight?
> > Keith
> I think it's clear that no. They just has to check (subscribe) to whatever the
> object has in its own interest. For the driver example the line of sight
> straight ahead should be the first priority of its interests (unless driving
> backwards and other subtleties like that). So to be subscribed to events of the
> first semaphore he/she has in front is mandatory but only while the semaphore is
> in front. Once he/she pass the semaphore he/she don't worry aout it anymore
> (unsuscribes events from that semaphore).
> I hope to be understandable.
A scheme described here leads to setting up listeners manually, e.g. instead of:
driver interestedIn: SemaphoreLight
driver noLongerinterestedIn: SemaphoreLight
your scheme means something like:
semaphore interestedBy: driver.
semaphore noLongerInterestedBy: driver.
so, to set-up a wiring you need to have visible both instances of
driver and semaphore in some code to wire them up, which is not always
simple because they can be placed using complex hierarchy like:
| car -- driver
crossroads -- semaphore
> seaside mailing list
> seaside at lists.squeakfoundation.org
Igor Stasenko AKA sig.
More information about the seaside