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

发布于 2024-11-18 17:34:02 字数 729 浏览 1 评论 0原文

我有一个包含 4 个视图的 Eclipse 插件。一个编程功能必须位于这些视图的“上方”,将它们连接在一起。我将其称为“大师”

有人可以建议此功能的最佳位置吗?实际上,我希望“主”在应用程序打开并且视图已初始化后启动。

在我生成的 RCP 应用程序插件中,我有一个 Activitor、一个 Client、一个 Perspective、一个 ApplicationActionBarAdvisor、一个 ApplicationWorkbenchAdvisor 和一个 ApplicationWorkbenchWindowAdvisor。这些似乎都不适合接待“主人”。

编辑:经过进一步调查,我怀疑 ApplicationWindowAdvisor 掌握了我的答案。它有许多可以被重写的方法来跳转应用程序生命周期阶段。与此问题相关的似乎是: postStartuppostWindowOpenpostWindowCreate

我将不胜感激任何关于调用哪个方法的指示创建/初始化所有视图后。

编辑 2:更多谷歌搜索公开了 org.eclipse.ui.startup 的使用 扩展点,因为 IStartup.earlyStartup() 也在工作台之后运行 完全开始了。

干杯, 伊恩

I've got an Eclipse plugin that contains 4 views. A piece of programming functionality must sit 'above' these views, tying them together. I'll call it the 'master'

Can anybody advise on the best location for this functionality? Really, I want the 'master' to start once the application is open and the views have been initialised.

In my generated RCP application plugin I have an Activitor, a Client, a Perspective, an ApplicationActionBarAdvisor, and ApplicationWorkbenchAdvisor, and an ApplicationWorkbenchWindowAdvisor. None of these seem suitable for hosting the 'master'.

Edit: after a little further investigation I suspect the ApplicationWindowAdvisor holds my answer. It has a number of methods that may be overridden to jump into application lifecycle stages. The ones that appear to relate to this problem appear to be: postStartup, postWindowOpen, postWindowCreate

I'd appreciate any pointers on which method is called after all the views have been created/initialised.

Edit 2: more googling has exposed use of the org.eclipse.ui.startup
extension point, as IStartup.earlyStartup() is also run after the Workbench
was completely started.

cheers,
Ian

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

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

发布评论

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

评论(3

情释 2024-11-25 17:34:02

也许您可以定义一个 OSGi 服务(请参阅 Lars Vogel 的教程以了解详细的操作方法:http:// /www.vogella.de/articles/OSGi/article.html)。

该服务可以通过声明方式初始化,也可以使用您的插件激活器进行初始化;然后每个视图都可以连接到该服务。

另一方面,如果您想在视图之间进行通信,您可以简单地使用工作台选择服务 - 在这种情况下,所有视图都在某种程度上彼此独立地运行,没有中央控制。

编辑回应问题的变化:所提出的方法都与视图的打开(或关闭)无关。 postStartup在应用程序启动后执行; postWindowOpen 在窗口打开后执行;而 postWindowCreate 在窗口创建之后、打开之前打开。

EarlyStartup() 可以在工作台启动后执行,但它仍然不能确定相应的视图是否打开 - 视图的生命周期与窗口不同。

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

Maybe you could define an OSGi service (see the tutorial by Lars Vogel for detailed howto: http://www.vogella.de/articles/OSGi/article.html).

This service could be initialized either declaratively, or by using your plug-in activator; then each view could connect to this service.

On the other hand, if you want to communicate between the views, you could simple use the workbench selection service - in this case, all views are operating somewhat independent of each other, without central control.

Edit Responding to the changes in the question: neither proposed methods have anything to do with the opening (or closing) of the views. The postStartup is executed after the application starts; postWindowOpen is executed after the window is opened; while postWindowCreate is opened after the window is created, but before its opened.

The earlyStartup() makes it possible to execute after the workbench was started, but it still does not makes sure whether the corresponding views are opened - views have a different life-cycle then windows.

Globally, you have to provide some common service that can be used by each of the views; this can registered at most points of the application lifecycle - you should choose the one that fits your need best.

青衫儰鉨ミ守葔 2024-11-25 17:34:02

我认为你正在混淆概念。算法不适用于视图,而是适用于视图显示的模型

视图只不过是一个窗口,它将内存中的位转换为用户认为有用的东西。

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

您的算法应该订阅所有四个模型的事件并完成其工作,将结果放入另一个模型中,以便相同或其他视图可以获取它。

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

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

I think you're mixing concepts. Algorithms don't work on views but on the models which the views show.

A view is nothing but a window which transforms bits in memory to something a user can find useful.

So what you really want is to separate the models in your views from the views themselves. That will also make testing much more simple. Have them publish events when they are change.

Your algorithm should subscribe to the events of all four models and do its work, putting the result in another model where the same or other views can pick it up.

In the views, also subscribe to the appropriate events which your models emit and update them accordingly.

This way, you can separate the model from the views. You won't get into trouble when the user rearranges views or closes them.

恋你朝朝暮暮 2024-11-25 17:34:02

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

我不记得具体如何做到这一点,但我认为在扩展点声明上将视角设置为“固定”可能会成功。

I think the best you can do is setup a Perspective with those views and lock them, so the user may not close them.

I do not remember exactly how you can do this, but I think setting the perspective as 'fixed' on the extension point declaration might do the trick.

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