在Eclipse插件中，我放置了一个利用多个视图的算法

我有一个包含4个视图的Eclipse插件。一项编程功能必须位于这些视图的“上方”，将它们连接在一起。我叫它“主人”

有人能建议这个功能的最佳位置吗？真的，我希望在应用程序打开并初始化视图后启动“主控”

在我生成的RCP应用程序插件中，我有一个Activator、一个客户端、一个透视图、一个ApplicationActionBarAdvisor、一个ApplicationWorkbenchHadVisor和一个ApplicationWorkbenchWindowVisor。所有这些似乎都不适合作为“主人”的主人

编辑：经过进一步调查，我怀疑ApplicationWindowAdvisor持有我的答案。它有许多方法，可以覆盖这些方法以跳转到应用程序生命周期阶段。与此问题相关的似乎是：postStartup，postWindowOpen，postWindowCreate

我希望在创建/初始化所有视图后，能有任何关于调用哪个方法的指针

编辑2：更多的谷歌搜索暴露了org.eclipse.ui.startup的使用 扩展点，如IStartup.earlyStartup（）也在工作台之后运行 完全启动了

干杯，

---

Ian

我认为你能做的最好的事情就是用这些视图设置一个透视图并锁定它们，这样用户就不会关闭它们

---

我不清楚您是如何做到这一点的，但我认为在扩展点声明中将透视图设置为“固定”可能就可以做到这一点。

也许您可以定义OSGi服务（请参阅Lars Vogel的教程了解详细的操作方法：）

此服务可以声明式初始化，也可以使用插件激活器初始化；然后每个视图都可以连接到此服务

另一方面，如果希望在视图之间进行通信，可以简单地使用workbench选择服务——在本例中，所有视图都在某种程度上相互独立地运行，而不需要中央控制

编辑响应问题中的更改：两种建议的方法都与视图的打开（或关闭）无关。启动后在应用程序启动后执行postWindowOpen在窗口打开后执行；而postWindowCreate在创建窗口后但在其打开之前打开

earlyStartup（）允许在工作台启动后执行，但它仍然不能确定是否打开了相应的视图-视图的生命周期与windows不同

---

在全球范围内，您必须提供一些可供每个视图使用的公共服务；这可以在应用程序生命周期的大多数时间点注册-您应该选择最适合您需要的一个。

我认为您在混合概念。算法不适用于视图，但适用于视图显示的模型

视图只不过是一个窗口，它将内存中的位转换为用户可以找到的有用的内容

因此，您真正想要的是将视图中的模型与视图本身分开。这也将使测试更加简单。让他们在事件发生更改时发布事件

您的算法应该订阅所有四个模型的事件并执行其工作，将结果放在另一个模型中，相同或其他视图可以拾取它

在视图中，还订阅模型发出的适当事件并相应地更新它们

---

这样，可以将模型与视图分离。当用户重新排列视图或关闭视图时，您不会遇到麻烦。

注意：如果您没有锁定视图，而用户意外关闭了视图，他总是可以使用“重置透视…”恢复视图。您好，正如问题所示，新插件向导为我提供了透视图。插件清单编辑器允许我为每个视图创建一个“perspectiveExtension”，并将其标记为不可关闭。嗨，我同意你的建议。我正在开发一个MVP设计，但是有4V（视图）。您描述的算法在我的模型中。我现在需要找到一个整洁的位置来放置将模型与视图联系起来的“P”。MVP中有4*V可能看起来很奇怪，但它们实际上只是一个视图：我只是想允许用户拖出并独立调整视图的各个部分。你能推荐一下P代码的位置吗？理想情况下，我希望在启动完成并实现视图后触发处理。为什么？只要在模型准备好后开始处理，让视图自行处理即可。尽量避免紧耦合。对你来说，事件驱动的方法应该很有效。啊，我明白了。在应用程序启动时创建模型，然后让视图在初始化后将自己注册到模型中。我不能让UI完全由视图驱动，因为视图显示通过网络接收的数据，并根据网络活动启用/禁用。是的。创建一个全局“事件”服务或其他东西，让模型的每个组件通过这个全局中心发布事件。任何相关方都可以从中心订阅活动。例如，视图可以响应“计算已完成”或“行已更新”事件来刷新自己。可能是建议。我喜欢Lars的工作，我没有意识到OSGI是一种我应该考虑的技术（我只是希望扩展新插件向导提供的功能-我已经根据对此的进一步研究更新了这个问题）。OSGI已经在所有RCP应用程序中可用，所以如果你愿意，可以使用它。然而，我更新了我的答案，为您编辑的问题提供了一些反馈。“OSGI已经……”。是的，佐尔坦，我很感激它在RCP工具箱里