Flex、RobotLegs:您必须协调可视组件的所有子组件吗?

发布于 2024-10-04 00:13:09 字数 433 浏览 4 评论 0原文

在 RobotLegs 的示例中,似乎中介器用于每个按钮/文本区域,而不是包含这些子项的自定义组件。这会非常耗时,不是吗?

来自 Joel Hooks InsideRia 示例

依赖注入可以更好地工作 明确的类。这意味着什么 是通过将 TextArea 扩展到我们的 我们正在创建新的 MessageView 类 一个特定的视图组件 依赖注入来执行操作。这 如果我们的应用程序是很重要的 有多个 TextAreas 服务 不同的目的。通过划分我们的 这样上课,我们就清楚了 定义课程的意图和 允许依赖注入 有效完成工作的工具。

In the examples for RobotLegs, it appears that mediators are used on every button/textArea, rather than on the custom component that contains these children. This would be very time consuming would it not?

From Joel Hooks InsideRia Example

Dependency injection works better with
unambiguous classes. What this means
is that by extending TextArea into our
new MessageView class, we are creating
a specific view component for the
dependency injection to act upon. This
is important if our application were
to have several TextAreas that served
different purposes. By dividing up our
classes in this way, we are clearly
defining the intent of the class and
allowing for the dependency injection
tools to do their jobs effectively.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

东风软 2024-10-11 00:13:09

不,不要调解每个子组件。您的组件应该组织成执行相关操作的组。在示例中,组件非常简单,并没有反映真实应用程序的样子。

No, don't mediate every child component. Your components should be organized into groups that perform related actions. In the examples the components are extremely simple and do not reflect what a real application would look like.

望她远 2024-10-11 00:13:09

我使用的一个经验法则是考虑该组件是否需要与应用程序的其余部分进行任何通信,或者它是否只是整个应用程序的一部分。请记住,中介器仅用作视图和应用程序之间的桥梁。

例如,如果我有一个带有表单的视图(假设一个登录表单),我不会调解所有子组件(文本字段、按钮等),因为这毫无意义,并且会导致类和类的激增。运行时的对象。当我做我所想的形式时,视图本身是什么?应用程序的其他部分应该用它做什么?
当用户填写表单并单击按钮时,视图将调度一个事件(本例中为 LoginRequestEvent),然后中介器应重新调度该事件,从而使中介器非常精简。

但通过该框架的练习,你会感觉到你应该调解什么。例如,在一个应用程序中,我调解列表的每个项目渲染器,而在其他应用程序中,我调解具有两个或三个导航内容的视图堆栈。

希望有帮助

One rule of thumbs I use is thinking if that component needs any communication with the rest of the application, or if its only a part of a whole. Keep in mind that mediator are only intended to serve as a bridge between the view and the app.

For example, if I've a view with a form (asume a login form) I don't mediate all the child components (the textfields, the buttons, etc.) because it would be pointless and would have a proliferation of classes and objects on runtime. When I do the form I think, what does the view by its own? and what the other parts of the app should do with it?
When the user fills the form and clicks a button, the view dispatches an event (LoginRequestEvent, for this case), and then the mediator should redispatch that event, making the mediator very lean.

But with practice of the framework, you'll come up with this feel of what you shold mediate. For instance, in one app I mediate every item renderer of a list, and on other I mediate a view stack with two or three navigation contents.

Hope it helps

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文