3.1 のメカニズムと API を採用する場合に必要な変更

このセクションでは、3.1 のメカニズムと API を採用するように 3.0 プラグインを変更する場合に必要な変更について説明します。

プラットフォームによる取り消し/やり直しのサポート

Eclipse 3.1 は、取り消し可能な操作と、実行された操作、取り消された操作、およびやり直された操作を追跡する共用の操作ヒストリーを定義するための、新規インフラストラクチャーを提供しています。アドオン・プラグインで提供されている各種取り消しフレームワークは、時間が経てばプラットフォーム操作のサポートにマイグレーションされるはずなので、これらのフレームワークのクライアントは、より深くプラットフォームと統合し、それぞれの取り消し可能操作を他のプラグイン・ビューおよびエディターでの取り消しに使用できるようにすることができます。プラグインに取り消しサポートを追加するための基本情報については、『取り消し可能操作』を参照してください。すでに取り消しサポートを定義しているプラグイン、または別のフレームワークを使用するプラグインを、以下で説明しているように、段階を追って新規の取り消しサポートにマイグレーションできます。

IUndoableOperation へのプラグイン固有の操作 (コマンド) クラスのマイグレーション

取り消し可能操作を記述しているクラスをすでに定義しているプラグインは、その操作/コマンド・クラスに IUndoableOperation インターフェースの実装を追加する必要があります。プラグインでは、古いフレームワークをヒストリー (コマンド・スタック) の管理に使用することは必要に応じて可能ですが、IUndoableOperation のインターフェースを提供すると、プラグインのクライアントは、プラットフォームの操作ヒストリー内の同じ操作を使用したり、別のプラグイン取り消し可能操作をミックス・アンド・マッチしたりすることができます。この戦略は、新規の操作フレームワークにマイグレーションするために SDK テキスト・エディターが使用する戦略に類似しています。インターフェースを直接マッピングできない場合は、ラッパーを使用して IUndoableOperation プロトコルを従来の取り消しオブジェクトにマップすることができます。この戦略は、Platform/JDT リファクタリング・サポートが使用します。IUndoableOperation を操作/コマンド・クラスにマイグレーションすることにより、プラグインを完全にマイグレーションしなくても、さまざまなフレームワークの取り消し可能操作を他のプラグインが利用することができるので、このマイグレーションは重要なステップです。

IOperationHistory を使用したコマンド・スタックのマイグレーション

取り消し可能操作またはコマンドを IUndoableOperation で表しておくと、取り消し可能操作およびやり直し可能操作を追跡し続けるための取り消しヒストリー (コマンド・スタック) を表す IUndoContext を定義することによって、その取り消しヒストリーを定義しているプラグインを、プラットフォームの操作ヒストリーにマイグレーションすることができます。ローカル側で以前に管理されていた取り消しヒストリーは、共通の操作ヒストリーにマージすることができます。それを行うには、各パーツまたは各モデルごとに固有の取り消しコンテキストを定義し、各操作に適した取り消しコンテキストを追加し、そしてプラットフォームの操作ヒストリーに操作を追加します。よりグローバルな有効範囲を持つ取り消しヒストリーを実装できます。この実装は、その取り消し有効範囲を表す固有の取り消しコンテキストを定義し、そのコンテキストを各操作に割り当て、そしてその操作をプラットフォームの操作ヒストリーに追加して行います。取り消しコンテキストの作成、その割り当て、およびプラットフォームの操作ヒストリーへの操作の追加の例については、『取り消し可能操作』を参照してください。

ワークベンチに対するグローバルな取り消し可能操作の定義

ナビゲーターやパッケージ・エクスプローラーなどのワークベンチのビューからプラグインの操作を取り消し可能にするには、それぞれのプラグインの操作にワークベンチの取り消しコンテキストを割り当てる必要があります。 この取り消しコンテキストの詳細や、ワークベンチおよびヘッドレス・プラグインの両方を使用してこの取り消しコンテキストを取り出す方法の詳細については、『取り消し可能操作』を参照してください。

プラットフォームの取り消し/やり直しアクション・ハンドラー

取り消しインフラストラクチャーや取り消し可能操作を定義していないが、プラットフォームの取り消しヒストリーへのアクセスを提供したいプラグインに対しては、ターゲットをグローバルな取り消しおよびやり直しアクション・ハンドラーから、新しい共通の取り消しおよびやり直しアクション・ハンドラーへの変更を検討してください。アクション・ハンドラーには、表示する取り消しおよびやり直しヒストリーを指定する取り消しコンテキストを割り当てる必要があります。プラグインは、そのローカル側で定義されている取り消しコンテキストを使用して、「部分的にローカルな」取り消しおよびやり直しヒストリーを表示することができます。ワークベンチの取り消しコンテキストを使用すると、ワークベンチ全体の取り消しおよびやり直しヒストリーを表示することができます。この場合も、『取り消し可能操作』に詳細な例が記載されています。

共通アクション・ハンドラーへのテキスト操作アクションのマイグレーション

テキスト・エディターの取り消しおよびやり直しアクションのマイグレーションは、グローバルな取り消し/やり直しアクション・ハンドラーの単純なターゲット変更とは少し異なっています。AbstractTextEditor フレームワークでは、パラメーター化された TextOperationAction を使用する共通テキスト・アクションが定義されています。これらのアクションは、ローカル側のフレームワークに保管され、エディターのテキスト操作のターゲットに各種コマンドをディスパッチするために使用されます。テキストの取り消しが正しく動作するためには、適切な ID (ITextEditorActionConstants.REDO および ITextEditorActionConstants.UNDO) を持つテキスト操作アクションがテキスト・エディター・フレームワークに不可欠になります。

AbstractTextEditor は、共通のアクション・ハンドラーを作成するためにマイグレーションされていますが、依然として従来の ID を使用して TextOperationAction テーブルにアクション・ハンドラーを割り当てています。このようにすることで、従来の手法でアクションの取り出しと操作の実行を行い、新規の取り消しおよびやり直しアクション・ハンドラーを取り出すことができます。AbstractTextEditor 階層内のテキスト・エディターは、この振る舞いを継承します。

この振る舞いを AbstractTextEditor から継承しないエディターの場合は、既存の取り消しおよびやり直しアクションをマイグレーションして、新規のハンドラーを使用する必要があります。従来の取り消しおよびやり直し TextOperationActions が使用する JFace Text 取り消しマネージャー API はまだサポートされているので、これらのアクションを持つエディターは、まだローカルの取り消しをサポートしています。ただし、取り消しおよびやり直しアクション・ラベルは、使用可能な取り消しまたはやり直し操作の名前を表示する新規の Eclipse SDK の取り消し/やり直しアクションとは整合しなくなります。共通の取り消しおよびやり直しアクション・ハンドラーを作成するには、アクション・ハンドラーの作成時に、テキスト・ビューアーの取り消しマネージャーが使用する取り消しコンテキストを使用し、適切な ITextEditorActionConstants ID を使用してそれらのハンドラーをエディターに設定する必要があります。詳細な例については、AbstractTextEditor.createUndoRedoActions() および AbstractTextEditor.getUndoContext() を参照してください。それぞれのエディターのアクション・バーを追加するのに EditorActionBarContributor サブクラスが不可欠なエディターは、アクティブ・エディターの設定時に、取り消しおよびやり直しアクション・ハンドラーを作成し、それらを設定することにより、類似の手法を使用することができます。

ヘルプの機能拡張

情報の検索

検索ページを「検索」ダイアログに提供しているプラグインの場合は、その情報スタイル検索をすべて、統合化された検索エンジンに移植する必要があります。3.1 以降は、すべての情報スタイル検索は、ワークベンチ生成物検索から分離されています。情報検索エンジンはバックグラウンド・ジョブとして並列で実行され、その結果は新規の「ヘルプ」ビューで照合されます。詳しくは、『ヘルプ検索』を参照してください。

ダイナミック・ヘルプ

新規のダイナミック・ヘルプ・ビューは、ワークベンチのパーツおよびダイアログ内のウィジェットに静的に関連付けられている既存のコンテキスト ID で動作します。ただし、自分でヘルプ・イベントをキャッチし、ヘルプを表示する場合は、ダイナミック・ヘルプ・ビューに役立つものは何も表示されません。この問題を修正するには、『ダイナミック・コンテキスト・ヘルプ』で説明されている新規の IContextProvider インターフェースに適合している必要があります。