本节描述在尝试将 3.0 插件更改为采用 3.1 机制和 API 时所需进行的更改。
Eclipse 3.1 提供了新的基础结构来定义可撤销的操作和共享操作历史记录,后者用来跟踪已执行的、已撤销的和已重做的操作。随着时间的推移,您应该将插件提供的各种撤销框架迁移到平台操作支持,以便这些框架的客户机可以更深入地与平台集成,并使它们的可撤销操作可以在其他插件视图和编辑器中撤销。请参阅可撤销的操作文档以获取有关对插件添加撤销支持的基本信息。可以将已定义了撤销支持或使用另一框架的插件分阶段迁移到新的撤销支持,如下所述。
对于已定义了用于描述其可撤销操作的类的插件,应该将接口 IUndoableOperation 的实现添加到它们的操作/命令类中。插件在必要时仍然可以使用旧框架来管理历史记录(命令堆栈),但通过为 IUndoableOperation 提供一个接口,就可以允许插件的客户机使用平台操作历史记录中的那些操作以及搭配使用来自不同插件的可撤销操作。此策略与 SDK 文本编辑器用来迁移到新操作框架的策略类似。如果不能直接映射该接口,则可以使用包装器来将 IUndoableOperation 协议映射到旧的撤销对象。平台/JDT 重构支持使用的就是此策略。从操作/命令类到 IUndoableOperation 的迁移是一个重要的步骤,这是因为它允许来自不同框架的可撤销操作可以被其他插件利用,而完全不需要对任何插件进行迁移。
一旦使用 IUndoableOperation 来表示可撤销操作或命令,定义了撤销历史记录(命令堆栈)以便跟踪可撤销和可重做操作的插件就可以通过定义表示其撤销历史记录的 IUndoContext 来迁移到平台操作历史记录。通过为每个部件或每个模型对象定义唯一的撤销上下文,对每个操作添加适当的撤销上下文,然后将该操作添加到平台操作历史记录中,就可以将先前以局部方式管理的撤销历史记录合并到公共操作历史记录中。通过定义唯一的撤销上下文来表示撤销作用域,对每个操作指定该上下文,然后将该操作添加到平台操作历史记录中,可以实现更全局作用域的撤销历史记录。请参阅可撤销的操作文档以获取有关创建撤销上下文、指定撤销上下文以及将操作添加到平台操作历史记录的示例。
如果插件希望它们的操作能够从工作台视图(例如“导航器”或“包资源管理器”)中撤销,则应该对它们的操作指定工作台撤销上下文。请参阅可撤销的操作文档以获取有关此撤销上下文以及工作台和无外设插件如何检索它的更多信息。
对于那些未定义撤销基础结构或可撤销操作,但希望能够访问平台撤销历史记录的插件来说,应该考虑使用新的公共撤销和重做操作处理程序来调整全局撤销和重做操作处理程序。应该对操作处理程序指定撤销上下文,该上下文指定要显示的撤销和重做历史记录。插件可以使用它们以局部方式定义的撤销上下文来显示“部件局部的”撤销和重做历史记录。可以使用工作台撤销上下文来显示工作台范围的撤销和重做历史记录。同样,可撤销的操作文档提供了完整的示例。
文本编辑器撤销和重做操作的迁移与简单地重新定位全局撤销/重做操作处理程序略有不同。AbstractTextEditor 框架使用参数化的 TextOperationAction 来定义公共文本操作。这些操作以局部方式存储在框架中,并且用来将各种命令分派到编辑器的文本操作目标。为了使文本撤销功能正常发挥作用,文本编辑器框架要求必须存在具有正确标识(ITextEditorActionConstants.REDO 和 ITextEditorActionConstants.UNDO)的文本操作。
AbstractTextEditor 已被迁移,现在,它能够创建公共操作处理程序,但仍然使用它们的旧标识来将它们指定给 TextOperationAction 表。因此,可以使用用来检索动作和执行操作的旧技术来检索新的撤销和重做操作处理程序。AbstractTextEditor 层次结构中的文本编辑器将继承此行为。
对于未从 AbstractTextEditor 继承此行为的编辑器来说,应该考虑迁移任何现有的撤销和重做操作以使用新的处理程序。使用旧的撤销和重做 TextOperationAction 的编辑器将仍然支持局部撤销,这是因为这些操作所使用的 JFace 文本撤销管理器 API 仍然受支持。但是,撤销和重做操作标注将与新的 Eclipse SDK 撤销/重做操作不一致,后者显示的是可用的撤销/重做操作的名称。要创建公共的撤销和重做操作处理程序,在创建操作处理程序时应该使用文本查看器的撤销管理器所使用的撤销上下文,并且应该使用适当的 ITextEditorActionConstants 标识来将那些处理程序放置到编辑器中。请参阅 AbstractTextEditor.createUndoRedoActions() 和 AbstractTextEditor.getUndoContext() 以获取详细的示例。对于那些依靠 EditorActionBarContributor 子类来对它们的编辑器操作栏添加内容的编辑器来说,可以使用类似的技术,即创建撤销和重做操作处理程序并在设置活动编辑器时设置那些处理程序。
对搜索对话框添加搜索页面的插件应该考虑将其所有信息样式的搜索移植到联合搜索引擎。从 3.1 开始,所有信息样式的搜索都与工作台工件搜索分开。信息搜索引擎作为后台作业并行运行,它们的结果将被收集到新的“帮助”视图中。请参阅帮助搜索以了解更多详细信息。
新的动态“帮助”视图将使用现有的上下文标识,这些上下文标识与工作台部件和对话框中的窗口小部件静态关联。但是,如果您自行捕获帮助事件并显示帮助,动态“帮助”视图将无法显示任何有用的内容。要解决此问题,您应该采用新的 IContextProvider
接口,如动态上下文帮助文档所述。
对于发行版 3.1 来说,AbstractUIPlugin.getPreferenceStore() 返回的 org.eclipse.jface.preference.IPreferenceStore 将是 org.eclipse.ui.preferences.ScopedPreferenceStore 的实例。ScopedPreferenceStore 使用 org.eclipse.core.runtime.preferences API 来管理首选项。在 3.0 中,它使用兼容性层来与 org.eclipse.core.runtime.Preferences的实例进行交互。
在 3.1 中,我们已经消除了 IPreferenceStore 的歧义,使其对首选项更改事件中发送的值类型更加具体明确。AbstractUIPlugin#getPreferenceStore 中的 IPreferenceStore 的行为与以前相同,但现在它的指定更为清晰。
类型:添加至 IPreferenceStore 的 org.eclipse.jface.util.IPropertyChangeListener
可能会获得两种类型的旧值和新值 - 类型化表示或字符串表示。通过调用类型化 IPreferenceStore API(例如 setValue(String key, boolean value)
生成的任何事件均将生成一个类型化事件。但是,这些事件也可能通过生成无类型化事件(例如,针对首选项导入)的核心运行时首选项传播。属性侦听器需要对这两种情况做好准备。另请注意,类型化事件将不会传播基本类型,因此调用 setValue(String key, boolean value)
将产生一个旧值和新值均为布尔值的事件。
putValue:IPreferenceStore.putValue(String key, String value) 将不会生成更改事件。此 API 要用于没有侦听器对其进行响应的专用首选项。
initializeDefaultPreferences。在 Eclipse 3.0 中,建议不要使用此 API,因为它只有在使用兼容性层时才被激发。由于大多数插件依靠 AbstractUIPlugin#getPreferenceStore 来获取它们的首选项库,因此其在先前启动插件时激发。如果插件自身没有访问兼容性层,则可能不会激发此方法。我们建议您创建一个 org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer 来处理首选项初始化。