将事件分派给 popupmanager 而不引用实例
我对 Flex 4 相当有经验，但我仍然不需要框架（我喜欢自己做所有事情）并且也不想使用它们，我知道它的优点并且已经学会了如何使用其中之一，但仍然不行。
如何在主应用程序中调度事件并让 popupmanager 中的组件对该事件做出反应？所有这些都在主应用程序内调度事件，而不是将其瞄准 popupmanager 或组件实例，我希望能够触发该事件，而不关心谁得到它或者是否有人对此做出反应，所以如果可能的话那么我就不会关心跟踪所说的弹出窗口。
我已经从组件分派了一个事件，并通过冒泡事件在主应用程序中接收它，因此彼此不可知，现在我希望它向后。 注意：我已经使用了单例，但这不是我这次需要的方法。
I'm fairly experienced with Flex 4, but I still haven't needed frameworks yet (I like to do everything myself) and don't want to use them either, I know it's advantages and have learned how to use one of them, but still, no.
How can I dispatch an event in the main application and have a component inside a popupmanager to react to that event? All this dispatching the event within the main app and NOT aiming it to the popupmanager or the component instance, I want to be able to fire the event and not care about who gets it or if anyone reacts to it at all so if that is possible then I wouldn't care about keeping track of said popups.
I already dispatch an event from the component and receive it in the main application by bubbling the event and therefore being agnostic of each other, now I want it backwards.
Note: I have used singletons, but it's not the approach I need this time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我看来，您迫切需要 RobotLegs，您似乎在询问如何创建/使用事件总线系统，以便解耦您的组件，这正是 Robotlegs 的惊人之处。
您绝对还应该关注的一件事是 ActionScript 3 信号。 Signals 是一种创建强类型事件（如 .NET Framework）的方法，而不是神奇的字符串事件系统，并且是添加到任何 Flash/Flex 项目的一个非常简单的螺栓。
另一种常见的方式是中介者/控制器单例模式。假设这是一个汽车应用程序，我们有一个服务层，它在后台从服务器接收一些数据，同时我们的弹出窗口也在后面显示。我们解决这个问题的一种方法是为我们的数据创建一个基于单例的控制器，例如 PartsController。它还具有一些公共 const 信号，例如
SingalDataUpdated。弹出窗口现在可以执行类似PartsController.SignalDataUpdated.add(OnPartsUpdated)的操作。OnPartsUpdated是弹出窗口内的本地方法，现在可以根据需要对事件做出反应，并且与任何其他 UI 组件没有耦合。这是我们通常采用的方法，确保没有 UI 组件明确了解任何其他 UI 组件，而只与控制器通信。您需要确保的一件事是当弹出窗口关闭时删除信号列表器。不过，RobotLegs 再次为您完成了大部分工作，并鼓励一些非常出色的架构最佳实践。我强烈建议您阅读他们的文档并熟悉它。当您意识到它如何帮助您构建代码的模块化和可维护性时，它将改变您的生活。
祝你好运！
有关上下文和单例的更新
关于上下文的想法是创建一个称为应用程序上下文的单例，它存储其他单例的实例。 控制反转 (IoC) 和 RobotLegs 只是将事物连接在一起，所以它看起来并不像绝对的垃圾可以使用，但您可以使用简单的 IoC 注入器，例如 Swiz 或 SwiftSuspenders 构建的。因此，例如，您可能会点击某个特定的控制器，例如：
但是尝试以这种方式访问所有内容有点荒谬。 RobotLegs 来救援了。相反，在 RobotLegs 上下文中定义注入规则，因此如果组件通过注入元数据标记请求 UserController，则所有内容都会获得相同的 UserController。与单例完全相同，但在组件定义中是正确的；
现在，您的组件可以像控制器对象一样使用控制器对象，但它是由 RobotLegs 在构造时注入的。对于我和我的大多数产品，我构建了一些基本对象，例如 GroupBase、PanelBase、PopupPanelBase 等，这些对象扩展了适当的组件并已经具有所有控制器注入属性，因此从这些属性派生的任何组件都已根据需要连接到正确的控制器。
对于您的简单项目，更容易推出自己的项目，只需为您的上下文创建一个单例来保存控制器并以这种方式与应用程序的上下文进行通信。这些都是相当高层次的架构决策，每个人根据自己的经验、偏好或其他因素在这个级别上的工作方式有所不同。最重要的是它适合您，并且您对该架构感到满意。 RobotLegs 有助于使一切都非常解耦，这会带来一些意想不到的惊人好处。
祝你好运！
It sounds to me you are in desperate need of RobotLegs, you seem to be asking how to to create/use an event bus system in order to de-couple your components which is exactly what robotlegs is amazing at.
One thing you should definitely also look at is ActionScript 3 Signals. Signals is an approach to make strongly typed events like .NET Framework, instead of the magic strings event system, and is a fantastic easy bolt on addition to any Flash/Flex project.
Another way that is common is a mediator/controller singleton pattern. Let's say this is an automotive application, and we have a service layer that behind the scenes is receiving some data from the server, whilst at the same time our popup is behind displayed. One way we solve this problem is create a singleton based controller for our data like PartsController. It also has some public const Signals like
SingalDataUpdated. The popup can now do something likePartsController.SignalDataUpdated.add(OnPartsUpdated).OnPartsUpdatedis a local method inside the popup that can now react to the event as necessary and has no coupling to any other UI component. This is typically the approach we take and ensure that no UI component has explicit knowledge of any other UI component, and instead only talk to the controllers. One thing you need to ensure though is when the popup is closed remove the signal lister.Again though, RobotLegs does most of all these for you and encourages some very great architecural best-pracitces. I would highly recommend you read through their documenation and get familiar with it. It will change your life when you realize how modular and maintainable it helps make your code.
Good luck!
Update regarding context and singletons
The idea regarding a context is to create a single singleton known as your application's context that stores the instances of what would be your other singletons. Inversion of control (IoC) and RobotLegs just wires things together so it dosen't look like absolute crap to work with, but you can just use a simple IoC injector like Swiz or SwiftSuspenders which RobotLegs is built upon. So, for example, you might hit a particular controller like:
But that is a bit ridiculous to try to access everything this way. Here comes RobotLegs to the rescue. Instead define injection rules in your RobotLegs context, so if a component asks for a UserController via an inject metadata tag, everything would get the same UserController. Exactly like a singleton, but correctly so in your component define;
Now your component can work with the controller object as if it was its own, but instead it was injected in by RobotLegs on construction. For me and and most of my products I build a few base objects like
GroupBase,PanelBase,PopupPanelBase, etc. that extend the proper component and already have all the controller injection properties so any component derived from these already connect to the proper controllers as needed.For your simple project, it's like easier to roll your own and just create a single singleton for your context to hold your controllers and communicate with application's context that way. These are all pretty high level architecural decisions and everyone works differently at this level based on their experience, preference, or whatever. The most important thing is that it works for you, and you are comfortable with the architecture. RobotLegs helps make everything very decoupled which has some amazing unforseen benefits later.
Good luck!
如果我理解这个问题：
在弹出组件中，您可以执行以下操作：
现在，由主 Application 类分派的 myCustomEvent 的任何实例都将触发弹出窗口中的处理程序。此外，任何冒泡到主应用程序类的 myCustomEvent 实例都将触发弹出窗口中的处理程序。
我不确定这是否是一个好主意。访问 topLevelApplication 将为您的弹出窗口添加外部依赖项，从长远来看，这可能会减少所述组件的重复使用。我不会不假思索地做出访问 topLevelApplication 的决定。
如果您想问不同的问题；从你的帖子中我不清楚，我觉得这有点令人困惑。
If I understand the question:
Inside your pop up component, you can do something like this:
Now any instances of the myCustomEvent that are dispatched by the main Application class will fire the handler in the popup. Also, any instance of the myCustomEvent that bubble up to to the main Application class will fire the handler in the popup.
I'm not sure if this is a good idea. Accessing the topLevelApplication will add external dependencies to your pop up which may reduce re-use of said component in the long term. Accessing the topLevelApplication is not a decision I would take on without thought.
If you were trying to ask a different question; it is unclear to me from your post, which I found kind of confusing.
进一步研究 Flextras.com 的说法（我猜是 Jeffry Houser），这一壮举是不可能的，事件永远不会向孩子冒泡，只会向父母冒泡。
因此，这必须通过中央事件存储库方法来完成，这也是框架主要采用的方式。
这确实是某些框架（如 Robotlegs）中发现的依赖注入解决的问题之一。
Looking further into what Flextras.com said (Jeffry Houser I presume), this feat is impossible, events never bubble to children, only to parents.
Therefore, this has to be done in a central event repository approach, which is the way frameworks do it mostly.
This is indeed one of the problems solved by dependencies injection found in some frameworks as robotlegs.