Hi Ryan, we are running Cairngorm with UM extensions. Theoretically I need to dispatch a UM event with callback where that callback is to a component other than the dispatching component. And because source and destination are "so far apart" conventional bubbling is not an option. Scenario: Because site visitors can be visitors or clients, the login component is just one child of several of a parent component. When a site visitor attempts to log on, Cairngorm/UM handles event propagation and handling, including saving server results in modelLocator VO etc. But if the login is successful, other components need to react - their functions must be called. One such component is a child of a child that is a peer of the login component. Even if I could grab a reference to the destination component function, and send it with the UM event from the source component, this feels like ugly hardcoding. Waving a magic wand I would be able to dispatch an event from anywhere and listen for it anywhere, without the limitation of only being able to bubble up the parent chain. This seems totally logical to me as obviously it is illogical to have to design one's gui architecture based on who needs to talk to who. Thanks for listening :-)
Mic. --- In [email protected], "Ryan Graham" <ryan.gra...@...> wrote: > > > > In an app that has many parent and child components, how does one > > communicate "across bubbling chains"? I need to go up from a buried > > child component source to its parent, across to another of the > > parent's children, and down that chain to a child destination. Can > > this be done in Flex, or do I create my own event subscription > > component where anybody from anywhere can subscribe with a > > self.reference? > > > > Sounds like you're describing the controller's function in MVC > architecture. Usually an event is triggered by some sort of user > interaction in hopes of changing the state of the application in some > way. If you store the state in some sort of centralized model > somewhere, the controller can react to user events, update the model's > state properties accordingly, and let any part of the view that is bound > to the model update itself on property change. Is that the setup you are > running right now? Are you passing data with this event that other > components need? > > > > HTH, > > Ryan > > > > This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. >
