我的问题:使用Eclipse ConsoleManager类的优势在于将我的控制台放在视图中。
我在java中创建了自己的控制台(REPL),并希望将它与Eclipse集成。我知道有两种方法可以做到这一点:
创建一个插件视图,只显示我自己的文本窗格。 启动它的示例代码:
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().
showView(REPL_PLUGIN_ID, project.getName(), IWorkbenchPage.VIEW_ACTIVATE);
创建一个插件,实现IConsole界面并使用ConsoleManager添加它。 启动它的示例代码:
ConsolePlugin.getDefault().getConsoleManager().addConsoles(myConsoles)
由于我已经实现了控制台,我赞成View部分。我不是不愿意实现IConsole(以及所需的所有其他接口),但是,我只是没有看到它的优点。
Eclipse ConsoleManager必须在那里有充分的理由,它是什么?使用它的主要原因/优势是什么?
到目前为止我发现了什么:
实施IConsole的优势:
实施IConsole的缺点:
我试图让这个问题尽可能清楚,但如果我能详细说明/澄清任何事情,请在评论中告诉我。
答案 0 :(得分:1)
正如之前引用的wiki条目所述,控制台视图主要用于使用traditional
之类的System.out.print
代码的简单端口。
一些插件(如SVN和CVS代码)使用Console视图提供命令的传统输出,但也提供其他视图和对话框,以提供更多或更好的信息。
因此,如果您从头开始开发Eclipse插件,我会说您创建自己的视图。希望您可以提供更多操作数据的操作,而不是在Console视图中提供。如果合适,你可以也提供像SVN那样的控制台视图。
答案 1 :(得分:1)
优势在于统一的用户体验。 Eclipse有几个用户习惯的通用视图:大纲,属性,问题视图,控制台等。想象一下,如果每个人都添加自己的自定义视图而不是重用现有视图。会有溢出的透视图,每个透视图包含特定任务的自定义视图(或者,包含自定义视图的单个透视图)。因此,如果您的控制台属于控制台的概念 - 特定于任务(基于文本)的交互仅包含瞬态数据 - 那么您应该将“视图”实现为控制台。
答案 2 :(得分:0)
当这些工具移植到IDE使用时,此控制台输出通常会被更丰富的反馈形式所取代,例如视图,标记和装饰。但是,习惯于旧命令行输出的用户可能仍希望将此原始输出视为其他视觉形式反馈的替代方案。此类别中的工具可以使用“控制台”视图来编写此输出。
在Eclipse 3.0之前,每个需要类似控制台输出的插件都创建了自己的Console视图。 Eclipse 3.0提供了一个通用的Console视图,所有插件都可以写入该视图。该视图可以同时托管多个控制台文档,并允许用户在不同的控制台页面之间切换。