[Seaside] Menu component - communicating with root component
philippe.marschall at gmail.com
Sun Apr 20 09:42:16 UTC 2008
2008/4/20, Keith Hodges <keith_hodges at yahoo.co.uk>:
> Ramon Leon wrote:
> > > In migrating a complex Magritte form to use Magritte-scriptaculous, I
> successfully wire up the models so that a change in one select drop down,
> changes items in other fields in the same form. The child field which has
> changed needs to trigger its form, so that all of changes in all of the the
> relevant fields are received by the model, and then scriptaculous update
> rendering, of not just its own component, but one of its parents (at some
> level). Since it is the components onChanged: event and callback: which is
> triggered when the user has changed the select box, it is the component
> which needs to trigger the form and the update. But as per usual, the inner
> component has no means for dynamically discovering "what is the form id that
> I am in", or asking the relevant parent to update.
> > >
> > >
> > Isn't that the whole point of an event based system? Loosely coupled
> > systems are easier to compose into complex scenarios like this without
> > becoming bound to one scenario. Rather than all the children having
> > intimate knowledge about how they're hooked together, you make the system
> > dead simple, keep all the children totally ignorant, have them just fire
> > events, and use the parent as a mediator to coordinate all the necessary
> > actions.
> > Then all the coupling is in the parent, having references to all its
> > children, it is in a perfect position to know in this particular
> > scenario/context how the children need to interact, so it subscribes to
> > appropriate events and executes the necessary actions when those events
> > fired. The child need only trigger an event that something happened,
> > nothing more. I just don't see why you feel the child needs to do more
> > that.
> > Ramon Leon
> > http://onsmalltalk.com
> How does the child tell the parent of the event if it doesnt know the
It doesn't and that's the whole a point about it. All it does it
announces an event and the parent may listen to this event.
> Are you suggesting that every child has an announcer,
No, you'll generally have more broadly scoped announcers.
> and that the parent
> registers an interest in events happening to the child, when it adds the
> child. The problem I see with that is that it expects all of the parents to
> do the wiring to all of the children, thats a lot of wiring.
> And parents are a multitude of generic components such as rendered PRPages
> with an embedded component at some arbitary depth.
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside